[xwiki-devs] Special behavior of the "Main" space in XE 7.2?
Hi Devs, I started trying out XE 7.2 (SNAPSHOT from around 12:30 today) and I was very impressed, the changes look quite good! While playing with it, I had a question about how the "Main" space is handled. Here's what I did: from .../xwiki/bin/view/Main/, I clicked the "create" button and created a sub page, then a sub-sub page. Here's what I got: - .../xwiki/bin/view/SubPage/SubSubPage Although I was expecting this: - .../xwiki/bin/view/Main/SubPage/SubSubPage So I was wondering whether this was the expected behavior, and whether it had been discussed before? Congrats & Thanks, Guillaume
Hi, Yes, "this is not a bug, it's a feature!" :) I had documented it in a small paragraph [1] (see the note) but did not feel it was worthy to be mentioned in the release notes. Please feel free to rephrase if needed. It's not specifically about "Main", but about the current wiki's homepage (and "Main.WebHome" is the default homepage that can be changed from administration). The effort is to try to avoid the situation where a regular user lands on the homepage of the wiki (just accessed the wiki or maybe he clicked the logo) and wants to create a document. He enters the title and presses "create". Obviously his intention was to create a page, and, more often than not (IMO at least), his actual intention was to create a top level document and not a child document of the wiki's current homepage. Image the homepage gets changed to "Some.Deep.Document.As.Homepage". Without this "trick", a regular user would end up, by mistake IMO (and by using the "next-next-next" mindset), creating the document "Some.Deep.Document.As.Homepage.NewDocument". Even if the homepage remains the default one, I see no logical reason in spamming all the new documents with the "Main" prefix, the result being an artificially deeper hierarchy and longer URL. If a user really intended to create a document as a child of the homepage (rare usecase IMO), he has all the tools in the UI to simply do so. I agree that it's a minor consistency dent, but IMO the benefit justifies it. WDYT? (interested in more opinions on this since I`ve already had 2 eyebrows raised on this topic :) ) Thanks, Eduard --------- [1] http://platform.xwiki.org/xwiki/bin/view/Features/DocumentLifecycle#HByusing... On Fri, Sep 11, 2015 at 4:42 PM, Guillaume Lerouge <[email protected]> wrote:
Hi Devs,
I started trying out XE 7.2 (SNAPSHOT from around 12:30 today) and I was very impressed, the changes look quite good!
While playing with it, I had a question about how the "Main" space is handled. Here's what I did: from .../xwiki/bin/view/Main/, I clicked the "create" button and created a sub page, then a sub-sub page. Here's what I got:
- .../xwiki/bin/view/SubPage/SubSubPage
Although I was expecting this:
- .../xwiki/bin/view/Main/SubPage/SubSubPage
So I was wondering whether this was the expected behavior, and whether it had been discussed before?
Congrats & Thanks,
Guillaume _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Edy, thanks for the explanation. Please see my feedback below. On Fri, Sep 11, 2015 at 5:24 PM, Eduard Moraru <[email protected]> wrote:
Hi,
Yes, "this is not a bug, it's a feature!" :) I had documented it in a small paragraph [1] (see the note) but did not feel it was worthy to be mentioned in the release notes. Please feel free to rephrase if needed.
It's not specifically about "Main", but about the current wiki's homepage (and "Main.WebHome" is the default homepage that can be changed from administration).
Does this feature (changing the home page) still makes sense in the context of nested spaces? What is the point to define the home page as ".../A/B/C" when based on the new system, "C" is a sub-sub page? To me, with nested spaces the home page is always the same and cannot be changed. You may want to add a redirect, but this doesn't change the fact that the top page is the same.
The effort is to try to avoid the situation where a regular user lands on the homepage of the wiki (just accessed the wiki or maybe he clicked the logo) and wants to create a document. He enters the title and presses "create". Obviously his intention was to create a page, and, more often than not (IMO at least), his actual intention was to create a top level document and not a child document of the wiki's current homepage.
I agree with this. However, in that case, shouldn't the home page be simply *https://<server>/xwiki/bin/view/* instead of *https://<server>/xwiki/bin/view/Main/* ? Using short URLs, you could even have the home page under *https://<server>/ *and then subpages at *https://<server>/A, **https://<server>/A/B* and so on. This would be in line with what most CMS do and it would fix your issue: any page created from the home is a sub-page at the expected level. Image the homepage gets changed to "Some.Deep.Document.As.Homepage".
Without this "trick", a regular user would end up, by mistake IMO (and by using the "next-next-next" mindset), creating the document "Some.Deep.Document.As.Homepage.NewDocument".
As I said above, I actually think we should remove this feature in the context of nested spaces.
Even if the homepage remains the default one, I see no logical reason in spamming all the new documents with the "Main" prefix, the result being an artificially deeper hierarchy and longer URL.
Agreed. As mentioned above, ideally we'd remove it.
If a user really intended to create a document as a child of the homepage (rare usecase IMO), he has all the tools in the UI to simply do so.
I agree that it's a minor consistency dent, but IMO the benefit justifies it.
I don't quite agree that it's minor. One of the implied goals of nested spaces is to be able to have consistent URL naming (I know exactly where page *https://<server>/A/B/C *is). Having a special case for Main breaks this. Similarly, when on the home page on the main wiki, I don't understand why the breadcrumb shows both the "home" icon and "Home" text. Why keep both when the icon would be enough? Thanks, Guillaume WDYT? (interested in more opinions on this since I've already had 2
eyebrows raised on this topic :) )
Thanks, Eduard
--------- [1]
http://platform.xwiki.org/xwiki/bin/view/Features/DocumentLifecycle#HByusing...
On Fri, Sep 11, 2015 at 4:42 PM, Guillaume Lerouge <[email protected]> wrote:
Hi Devs,
I started trying out XE 7.2 (SNAPSHOT from around 12:30 today) and I was very impressed, the changes look quite good!
While playing with it, I had a question about how the "Main" space is handled. Here's what I did: from .../xwiki/bin/view/Main/, I clicked the "create" button and created a sub page, then a sub-sub page. Here's what I got:
- .../xwiki/bin/view/SubPage/SubSubPage
Although I was expecting this:
- .../xwiki/bin/view/Main/SubPage/SubSubPage
So I was wondering whether this was the expected behavior, and whether it had been discussed before?
Congrats & Thanks,
Guillaume _______________________________________________ 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, The current behavior was reached after many discussions. Currently the concept of main wiki is expressed as the 'home' icon, but is not tied to a particular space. This is something we preserved and is flexible enough for users with custom content to change the location of the homepage or assigned a different space, for a different subwiki. Also we needed to showcase differently spaces that are top level, vs. pages inside the Main space, while having the limited number of exceptions created for the breadcrumb. Also I wouldn't like that all the URL contain the word 'Main'. Imagine that besides the 'xwiki/bin/view/' we would need to also contain the homepage space? Although we have a convention that a certain page is displayed as homepage, this is not needed to be in the URL. 'home' icon is a link for the homepage, not a physical location. Currently the 'Main' space can contain pages useful for the display of the homepage, but is an 'optional' space. Thanks, Caty On Mon, Sep 14, 2015 at 11:25 AM, Guillaume Lerouge <[email protected]> wrote:
Hi Edy,
thanks for the explanation. Please see my feedback below.
On Fri, Sep 11, 2015 at 5:24 PM, Eduard Moraru <[email protected]> wrote:
Hi,
Yes, "this is not a bug, it's a feature!" :) I had documented it in a small paragraph [1] (see the note) but did not feel it was worthy to be mentioned in the release notes. Please feel free to rephrase if needed.
It's not specifically about "Main", but about the current wiki's homepage (and "Main.WebHome" is the default homepage that can be changed from administration).
Does this feature (changing the home page) still makes sense in the context of nested spaces? What is the point to define the home page as ".../A/B/C" when based on the new system, "C" is a sub-sub page?
To me, with nested spaces the home page is always the same and cannot be changed. You may want to add a redirect, but this doesn't change the fact that the top page is the same.
The effort is to try to avoid the situation where a regular user lands on the homepage of the wiki (just accessed the wiki or maybe he clicked the logo) and wants to create a document. He enters the title and presses "create". Obviously his intention was to create a page, and, more often than not (IMO at least), his actual intention was to create a top level document and not a child document of the wiki's current homepage.
I agree with this. However, in that case, shouldn't the home page be simply *https://<server>/xwiki/bin/view/* instead of *https://<server>/xwiki/bin/view/Main/* ?
Using short URLs, you could even have the home page under *https:// <server>/ *and then subpages at *https://<server>/A, **https://<server>/A/B* and so on. This would be in line with what most CMS do and it would fix your issue: any page created from the home is a sub-page at the expected level.
Image the homepage gets changed to "Some.Deep.Document.As.Homepage".
Without this "trick", a regular user would end up, by mistake IMO (and by using the "next-next-next" mindset), creating the document "Some.Deep.Document.As.Homepage.NewDocument".
As I said above, I actually think we should remove this feature in the context of nested spaces.
Even if the homepage remains the default one, I see no logical reason in spamming all the new documents with the "Main" prefix, the result being an artificially deeper hierarchy and longer URL.
Agreed. As mentioned above, ideally we'd remove it.
If a user really intended to create a document as a child of the homepage (rare usecase IMO), he has all the tools in the UI to simply do so.
I agree that it's a minor consistency dent, but IMO the benefit justifies it.
I don't quite agree that it's minor. One of the implied goals of nested spaces is to be able to have consistent URL naming (I know exactly where page *https://<server>/A/B/C *is). Having a special case for Main breaks this.
Similarly, when on the home page on the main wiki, I don't understand why the breadcrumb shows both the "home" icon and "Home" text. Why keep both when the icon would be enough?
Thanks,
Guillaume
WDYT? (interested in more opinions on this since I've already had 2
eyebrows raised on this topic :) )
Thanks, Eduard
--------- [1]
http://platform.xwiki.org/xwiki/bin/view/Features/DocumentLifecycle#HByusing...
On Fri, Sep 11, 2015 at 4:42 PM, Guillaume Lerouge <[email protected]> wrote:
Hi Devs,
I started trying out XE 7.2 (SNAPSHOT from around 12:30 today) and I
was
very impressed, the changes look quite good!
While playing with it, I had a question about how the "Main" space is handled. Here's what I did: from .../xwiki/bin/view/Main/, I clicked the "create" button and created a sub page, then a sub-sub page. Here's what I got:
- .../xwiki/bin/view/SubPage/SubSubPage
Although I was expecting this:
- .../xwiki/bin/view/Main/SubPage/SubSubPage
So I was wondering whether this was the expected behavior, and whether it had been discussed before?
Congrats & Thanks,
Guillaume _______________________________________________ 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
Hi Caty, thanks for your message. Please see my answers below. On Mon, Sep 14, 2015 at 11:22 AM, Ecaterina Moraru (Valica) < [email protected]> wrote:
Hi,
The current behavior was reached after many discussions.
I understand. However, I only got the time to actually try and test XE 7.2 last week. And based on what Edy said, I'm not the only one who was surprised by the current behavior :-)
Currently the concept of main wiki is expressed as the 'home' icon, but is not tied to a particular space. This is something we preserved and is flexible enough for users with custom content to change the location of the homepage or assigned a different space, for a different subwiki.
I understand this. I'm not questioning the current behavior, but the underlying assumption. Given the new paradigm we're implementing with nested spaces, why would an user want to change the location of the homepage? To me, it's like saying that you would want the top level folder on your computer to be something else than the hard drive itself. I don't understand why that would be useful. Do you have specific use cases in mind that I might be missing (other than "this feature existed before")? Also we needed to showcase differently spaces that are top level, vs. pages
inside the Main space, while having the limited number of exceptions created for the breadcrumb.
I think there are 2 separate problems here: 1. Where should we put all of the pages that are currently in the "Main" space if we decide that not all of them deserve to be top-level pages 2. Making it possible to have top-level pages in a coherent manner For 1., pages in the Main space could stay where they are for now. "Main" would be the legacy space where we put useful tools for the management of your wiki. I'm discussing the answer for 2. below. Also I wouldn't like that all the URL contain the word 'Main' Imagine that
besides the 'xwiki/bin/view/' we would need to also contain the homepage space?
My very point is that the home page wouldn't (shouldn't?) need to be "Main". It would be "". IE, there would be nothing in the URL to reflect it. It would be a representation of the wiki itself. I understand that technically this is not feasible right now and that we *need* to have a specific page be the home page, which is the role played by Main.WebHome. What I'm saying is that with the new system, I'd rather have *.../xwiki/bin/view/WebHome => **.../xwiki/bin/view/ *would be the whole wiki. That level would be the top level space (which is exactly what has been implemented by the way). Do you see what I mean?
Although we have a convention that a certain page is displayed as homepage, this is not needed to be in the URL. 'home' icon is a link for the homepage, not a physical location. Currently the 'Main' space can contain pages useful for the display of the homepage, but is an 'optional' space.
What I' suggesting is precisely that the home page be its own document at the very top of the hierarchy, ABOVE what is currently known as Main.WebHome. This is why while the user is on this page, she should see only the home icon. Is this making what I mean clearer? I'm just suggesting we push things one step further in the direction that has already been established. Thanks, Guillaume Thanks,
Caty
On Mon, Sep 14, 2015 at 11:25 AM, Guillaume Lerouge <[email protected]> wrote:
Hi Edy,
thanks for the explanation. Please see my feedback below.
On Fri, Sep 11, 2015 at 5:24 PM, Eduard Moraru <[email protected]> wrote:
Hi,
Yes, "this is not a bug, it's a feature!" :) I had documented it in a small paragraph [1] (see the note) but did not feel it was worthy to be mentioned in the release notes. Please feel free to rephrase if needed.
It's not specifically about "Main", but about the current wiki's homepage (and "Main.WebHome" is the default homepage that can be changed from administration).
Does this feature (changing the home page) still makes sense in the context of nested spaces? What is the point to define the home page as ".../A/B/C" when based on the new system, "C" is a sub-sub page?
To me, with nested spaces the home page is always the same and cannot be changed. You may want to add a redirect, but this doesn't change the fact that the top page is the same.
The effort is to try to avoid the situation where a regular user lands on the homepage of the wiki (just accessed the wiki or maybe he clicked the logo) and wants to create a document. He enters the title and presses "create". Obviously his intention was to create a page, and, more often than not (IMO at least), his actual intention was to create a top level document and not a child document of the wiki's current homepage.
I agree with this. However, in that case, shouldn't the home page be simply *https://<server>/xwiki/bin/view/* instead of *https://<server>/xwiki/bin/view/Main/* ?
Using short URLs, you could even have the home page under *https:// <server>/ *and then subpages at *https://<server>/A, **https://<server>/A/B* and so on. This would be in line with what most CMS do and it would fix your issue: any page created from the home is a sub-page at the expected level.
Image the homepage gets changed to "Some.Deep.Document.As.Homepage".
Without this "trick", a regular user would end up, by mistake IMO (and by using the "next-next-next" mindset), creating the document "Some.Deep.Document.As.Homepage.NewDocument".
As I said above, I actually think we should remove this feature in the context of nested spaces.
Even if the homepage remains the default one, I see no logical reason in spamming all the new documents with the "Main" prefix, the result being an artificially deeper hierarchy and longer URL.
Agreed. As mentioned above, ideally we'd remove it.
If a user really intended to create a document as a child of the homepage (rare usecase IMO), he has all the tools in the UI to simply do so.
I agree that it's a minor consistency dent, but IMO the benefit justifies it.
I don't quite agree that it's minor. One of the implied goals of nested spaces is to be able to have consistent URL naming (I know exactly where page *https://<server>/A/B/C *is). Having a special case for Main breaks this.
Similarly, when on the home page on the main wiki, I don't understand why the breadcrumb shows both the "home" icon and "Home" text. Why keep both when the icon would be enough?
Thanks,
Guillaume
WDYT? (interested in more opinions on this since I've already had 2
eyebrows raised on this topic :) )
Thanks, Eduard
--------- [1]
http://platform.xwiki.org/xwiki/bin/view/Features/DocumentLifecycle#HByusing...
On Fri, Sep 11, 2015 at 4:42 PM, Guillaume Lerouge <
wrote:
Hi Devs,
I started trying out XE 7.2 (SNAPSHOT from around 12:30 today) and I was very impressed, the changes look quite good!
While playing with it, I had a question about how the "Main" space is handled. Here's what I did: from .../xwiki/bin/view/Main/, I clicked the "create" button and created a sub page, then a sub-sub page. Here's what I got:
- .../xwiki/bin/view/SubPage/SubSubPage
Although I was expecting this:
- .../xwiki/bin/view/Main/SubPage/SubSubPage
So I was wondering whether this was the expected behavior, and whether it had been discussed before?
Congrats & Thanks,
Guillaume _______________________________________________ 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
On Mon, Sep 14, 2015 at 6:26 PM, Guillaume Lerouge <[email protected]> wrote:
Hi Caty,
thanks for your message. Please see my answers below.
On Mon, Sep 14, 2015 at 11:22 AM, Ecaterina Moraru (Valica) < [email protected]> wrote:
Hi,
The current behavior was reached after many discussions.
I understand. However, I only got the time to actually try and test XE 7.2 last week. And based on what Edy said, I'm not the only one who was surprised by the current behavior :-)
Currently the concept of main wiki is expressed as the 'home' icon, but is not tied to a particular space. This is something we preserved and is flexible enough for users with custom content to change the location of the homepage or assigned a different space, for a different subwiki.
I understand this. I'm not questioning the current behavior, but the underlying assumption. Given the new paradigm we're implementing with nested spaces, why would an user want to change the location of the homepage? To me, it's like saying that you would want the top level folder on your computer to be something else than the hard drive itself. I don't understand why that would be useful.
Do you have specific use cases in mind that I might be missing (other than "this feature existed before")?
I think the main use case when you have old/imported from somewhere else content. Instead of having to copy all those pages inside Main space, you just import them and reassign the homepage.
Also we needed to showcase differently spaces that are top level, vs. pages
inside the Main space, while having the limited number of exceptions created for the breadcrumb.
I think there are 2 separate problems here:
1. Where should we put all of the pages that are currently in the "Main" space if we decide that not all of them deserve to be top-level pages 2. Making it possible to have top-level pages in a coherent manner
I don't think we have such a concept of top-level pages. Nothing in Main space is a top-level page (pages like Welcome are tool-pages). The only top-level/important page is Main.WebHome.
For 1., pages in the Main space could stay where they are for now. "Main" would be the legacy space where we put useful tools for the management of your wiki.
Also think about the pages in XWiki space, that are tool-pages.
I'm discussing the answer for 2. below.
Also I wouldn't like that all the URL contain the word 'Main' Imagine that
besides the 'xwiki/bin/view/' we would need to also contain the homepage space?
My very point is that the home page wouldn't (shouldn't?) need to be "Main". It would be "". IE, there would be nothing in the URL to reflect it. It would be a representation of the wiki itself.
I understand that technically this is not feasible right now and that we *need* to have a specific page be the home page, which is the role played by Main.WebHome. What I'm saying is that with the new system, I'd rather have *.../xwiki/bin/view/WebHome => **.../xwiki/bin/view/ *would be the whole wiki. That level would be the top level space (which is exactly what has been implemented by the way). Do you see what I mean?
I see what you mean and it would be ideal, but technically right now I don't think we can achieve that. And that's why all the problems and exceptions.
Although we have a convention that a certain page is displayed as homepage, this is not needed to be in the URL. 'home' icon is a link for the homepage, not a physical location. Currently the 'Main' space can contain pages useful for the display of the homepage, but is an 'optional' space.
What I' suggesting is precisely that the home page be its own document at the very top of the hierarchy, ABOVE what is currently known as Main.WebHome. This is why while the user is on this page, she should see only the home icon.
Is this making what I mean clearer? I'm just suggesting we push things one step further in the direction that has already been established.
:) sure, but how do we do it? Thanks, Caty
Thanks,
Guillaume
Thanks,
Caty
On Mon, Sep 14, 2015 at 11:25 AM, Guillaume Lerouge <[email protected]
wrote:
Hi Edy,
thanks for the explanation. Please see my feedback below.
On Fri, Sep 11, 2015 at 5:24 PM, Eduard Moraru <[email protected]> wrote:
Hi,
Yes, "this is not a bug, it's a feature!" :) I had documented it in a small paragraph [1] (see the note) but did not feel it was worthy to be mentioned in the release notes. Please feel free to rephrase if needed.
It's not specifically about "Main", but about the current wiki's homepage (and "Main.WebHome" is the default homepage that can be changed from administration).
Does this feature (changing the home page) still makes sense in the context of nested spaces? What is the point to define the home page as ".../A/B/C" when based on the new system, "C" is a sub-sub page?
To me, with nested spaces the home page is always the same and cannot be changed. You may want to add a redirect, but this doesn't change the fact that the top page is the same.
The effort is to try to avoid the situation where a regular user lands on the homepage of the wiki (just accessed the wiki or maybe he clicked the logo) and wants to create a document. He enters the title and presses "create". Obviously his intention was to create a page, and, more often than not (IMO at least), his actual intention was to create a top level document and not a child document of the wiki's current homepage.
I agree with this. However, in that case, shouldn't the home page be simply *https://<server>/xwiki/bin/view/* instead of *https://<server>/xwiki/bin/view/Main/* ?
Using short URLs, you could even have the home page under *https:// <server>/ *and then subpages at *https://<server>/A, **https://<server>/A/B* and so on. This would be in line with what most CMS do and it would fix your issue: any page created from the home is a sub-page at the expected level.
Image the homepage gets changed to "Some.Deep.Document.As.Homepage".
Without this "trick", a regular user would end up, by mistake IMO (and by using the "next-next-next" mindset), creating the document "Some.Deep.Document.As.Homepage.NewDocument".
As I said above, I actually think we should remove this feature in the context of nested spaces.
Even if the homepage remains the default one, I see no logical reason in spamming all the new documents with the "Main" prefix, the result being an artificially deeper hierarchy and longer URL.
Agreed. As mentioned above, ideally we'd remove it.
If a user really intended to create a document as a child of the homepage (rare usecase IMO), he has all the tools in the UI to simply do so.
I agree that it's a minor consistency dent, but IMO the benefit justifies it.
I don't quite agree that it's minor. One of the implied goals of nested spaces is to be able to have consistent URL naming (I know exactly where page *https://<server>/A/B/C *is). Having a special case for Main breaks this.
Similarly, when on the home page on the main wiki, I don't understand why the breadcrumb shows both the "home" icon and "Home" text. Why keep both when the icon would be enough?
Thanks,
Guillaume
WDYT? (interested in more opinions on this since I've already had 2
eyebrows raised on this topic :) )
Thanks, Eduard
--------- [1]
http://platform.xwiki.org/xwiki/bin/view/Features/DocumentLifecycle#HByusing...
On Fri, Sep 11, 2015 at 4:42 PM, Guillaume Lerouge <
wrote:
Hi Devs,
I started trying out XE 7.2 (SNAPSHOT from around 12:30 today) and I was very impressed, the changes look quite good!
While playing with it, I had a question about how the "Main" space is handled. Here's what I did: from .../xwiki/bin/view/Main/, I clicked the "create" button and created a sub page, then a sub-sub page. Here's what I got:
- .../xwiki/bin/view/SubPage/SubSubPage
Although I was expecting this:
- .../xwiki/bin/view/Main/SubPage/SubSubPage
So I was wondering whether this was the expected behavior, and whether it had been discussed before?
Congrats & Thanks,
Guillaume _______________________________________________ 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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi, On Tue, Sep 15, 2015 at 12:04 PM, Ecaterina Moraru (Valica) < [email protected]> wrote:
On Mon, Sep 14, 2015 at 6:26 PM, Guillaume Lerouge <[email protected]> wrote:
Hi Caty,
thanks for your message. Please see my answers below.
On Mon, Sep 14, 2015 at 11:22 AM, Ecaterina Moraru (Valica) < [email protected]> wrote:
Hi,
The current behavior was reached after many discussions.
I understand. However, I only got the time to actually try and test XE 7.2 last week. And based on what Edy said, I'm not the only one who was surprised by the current behavior :-)
Currently the concept of main wiki is expressed as the 'home' icon, but is not tied to a particular space. This is something we preserved and is flexible enough for users with custom content to change the location of the homepage or assigned a different space, for a different subwiki.
I understand this. I'm not questioning the current behavior, but the underlying assumption. Given the new paradigm we're implementing with nested spaces, why would an user want to change the location of the homepage? To me, it's like saying that you would want the top level folder on your computer to be something else than the hard drive itself. I don't understand why that would be useful.
Do you have specific use cases in mind that I might be missing (other than "this feature existed before")?
I think the main use case when you have old/imported from somewhere else content. Instead of having to copy all those pages inside Main space, you just import them and reassign the homepage.
Also we needed to showcase differently spaces that are top level, vs.
pages
inside the Main space, while having the limited number of exceptions created for the breadcrumb.
I think there are 2 separate problems here:
1. Where should we put all of the pages that are currently in the "Main" space if we decide that not all of them deserve to be top-level pages 2. Making it possible to have top-level pages in a coherent manner
I don't think we have such a concept of top-level pages. Nothing in Main space is a top-level page (pages like Welcome are tool-pages). The only top-level/important page is Main.WebHome.
For 1., pages in the Main space could stay where they are for now. "Main" would be the legacy space where we put useful tools for the management of your wiki.
Also think about the pages in XWiki space, that are tool-pages.
I'm discussing the answer for 2. below.
Also I wouldn't like that all the URL contain the word 'Main' Imagine
that
besides the 'xwiki/bin/view/' we would need to also contain the homepage space?
My very point is that the home page wouldn't (shouldn't?) need to be "Main". It would be "". IE, there would be nothing in the URL to reflect it. It would be a representation of the wiki itself.
I understand that technically this is not feasible right now and that we *need* to have a specific page be the home page, which is the role played by Main.WebHome. What I'm saying is that with the new system, I'd rather have *.../xwiki/bin/view/WebHome => **.../xwiki/bin/view/ *would be the whole wiki. That level would be the top level space (which is exactly what has been implemented by the way). Do you see what I mean?
I see what you mean and it would be ideal, but technically right now I don't think we can achieve that. And that's why all the problems and exceptions.
Although we have a convention that a certain page is displayed as homepage, this is not needed to be in the URL. 'home' icon is a link
for
the homepage, not a physical location. Currently the 'Main' space can contain pages useful for the display of the homepage, but is an 'optional' space.
What I' suggesting is precisely that the home page be its own document at the very top of the hierarchy, ABOVE what is currently known as Main.WebHome. This is why while the user is on this page, she should see only the home icon.
Is this making what I mean clearer? I'm just suggesting we push things one step further in the direction that has already been established.
:) sure, but how do we do it?
Usually, when hopeing for something like this to get done, I beg Vincent to find a way ;-) Guillaume Thanks,
Caty
Thanks,
Guillaume
Thanks,
Caty
On Mon, Sep 14, 2015 at 11:25 AM, Guillaume Lerouge <
wrote:
Hi Edy,
thanks for the explanation. Please see my feedback below.
On Fri, Sep 11, 2015 at 5:24 PM, Eduard Moraru <[email protected]
wrote:
Hi,
Yes, "this is not a bug, it's a feature!" :) I had documented it in a small paragraph [1] (see the note) but did not feel it was worthy to be mentioned in the release notes. Please feel free to rephrase if needed.
It's not specifically about "Main", but about the current wiki's homepage (and "Main.WebHome" is the default homepage that can be changed from administration).
Does this feature (changing the home page) still makes sense in the context of nested spaces? What is the point to define the home page as ".../A/B/C" when based on the new system, "C" is a sub-sub page?
To me, with nested spaces the home page is always the same and cannot be changed. You may want to add a redirect, but this doesn't change the fact that the top page is the same.
The effort is to try to avoid the situation where a regular user lands on the homepage of the wiki (just accessed the wiki or maybe he clicked the logo) and wants to create a document. He enters the title and presses "create". Obviously his intention was to create a page, and, more often than not (IMO at least), his actual intention was to create a top level document and not a child document of the wiki's current homepage.
I agree with this. However, in that case, shouldn't the home page be simply *https://<server>/xwiki/bin/view/* instead of *https://<server>/xwiki/bin/view/Main/* ?
Using short URLs, you could even have the home page under *https:// <server>/ *and then subpages at *https://<server>/A, **https://<server>/A/B* and so on. This would be in line with what most CMS do and it would fix your issue: any page created from the home is a sub-page at the expected level.
Image the homepage gets changed to "Some.Deep.Document.As.Homepage".
Without this "trick", a regular user would end up, by mistake IMO (and by using the "next-next-next" mindset), creating the document "Some.Deep.Document.As.Homepage.NewDocument".
As I said above, I actually think we should remove this feature in the context of nested spaces.
Even if the homepage remains the default one, I see no logical reason in spamming all the new documents with the "Main" prefix, the result being an artificially deeper hierarchy and longer URL.
Agreed. As mentioned above, ideally we'd remove it.
If a user really intended to create a document as a child of the homepage (rare usecase IMO), he has all the tools in the UI to simply do so.
I agree that it's a minor consistency dent, but IMO the benefit justifies it.
I don't quite agree that it's minor. One of the implied goals of nested spaces is to be able to have consistent URL naming (I know exactly where page *https://<server>/A/B/C *is). Having a special case for Main breaks this.
Similarly, when on the home page on the main wiki, I don't understand why the breadcrumb shows both the "home" icon and "Home" text. Why keep both when the icon would be enough?
Thanks,
Guillaume
WDYT? (interested in more opinions on this since I've already had 2
eyebrows raised on this topic :) )
Thanks, Eduard
--------- [1]
http://platform.xwiki.org/xwiki/bin/view/Features/DocumentLifecycle#HByusing...
On Fri, Sep 11, 2015 at 4:42 PM, Guillaume Lerouge <
wrote:
Hi Devs,
I started trying out XE 7.2 (SNAPSHOT from around 12:30 today) and I was very impressed, the changes look quite good!
While playing with it, I had a question about how the "Main" space is handled. Here's what I did: from .../xwiki/bin/view/Main/, I clicked the "create" button and created a sub page, then a sub-sub page. Here's what I got:
- .../xwiki/bin/view/SubPage/SubSubPage
Although I was expecting this:
- .../xwiki/bin/view/Main/SubPage/SubSubPage
So I was wondering whether this was the expected behavior, and whether it had been discussed before?
Congrats & Thanks,
Guillaume
Hi Guillaume, On Mon, Sep 14, 2015 at 6:26 PM, Guillaume Lerouge <[email protected]> wrote:
Hi Caty,
thanks for your message. Please see my answers below.
On Mon, Sep 14, 2015 at 11:22 AM, Ecaterina Moraru (Valica) < [email protected]> wrote:
Hi,
The current behavior was reached after many discussions.
I understand. However, I only got the time to actually try and test XE 7.2 last week. And based on what Edy said, I'm not the only one who was surprised by the current behavior :-)
Currently the concept of main wiki is expressed as the 'home' icon, but is not tied to a particular space. This is something we preserved and is flexible enough for users with custom content to change the location of the homepage or assigned a different space, for a different subwiki.
I understand this. I'm not questioning the current behavior, but the underlying assumption. Given the new paradigm we're implementing with nested spaces, why would an user want to change the location of the homepage? To me, it's like saying that you would want the top level folder on your computer to be something else than the hard drive itself. I don't understand why that would be useful.
The hard-drive is the wiki not the Main space. Or, if you want to be precise, the entire farm is the hard-drive, a wiki is a partition on that hard-drive and a space is a folder on a partition. The Main space is just one of the top level "folders". Blog, XWiki, Sandbox are also at the top level. And you can create new top level "folders". When you access XWiki you get redirected to the Main space by default but someone may want the Blog space to be opened by default.
Do you have specific use cases in mind that I might be missing (other than "this feature existed before")?
Also we needed to showcase differently spaces that are top level, vs. pages
inside the Main space, while having the limited number of exceptions created for the breadcrumb.
I think there are 2 separate problems here:
1. Where should we put all of the pages that are currently in the "Main" space if we decide that not all of them deserve to be top-level pages
Pages from the Main space are not top level. Main is top level, and Main is on the same level with Blog, Sandbox and XWiki. Check the document index tree. I have the feeling you're making a confusion.
2. Making it possible to have top-level pages in a coherent manner
For 1., pages in the Main space could stay where they are for now. "Main" would be the legacy space where we put useful tools for the management of your wiki.
I'm discussing the answer for 2. below.
Also I wouldn't like that all the URL contain the word 'Main' Imagine that
besides the 'xwiki/bin/view/' we would need to also contain the homepage space?
My very point is that the home page wouldn't (shouldn't?) need to be "Main". It would be "". IE, there would be nothing in the URL to reflect it. It would be a representation of the wiki itself.
I understand that technically this is not feasible right now and that we *need* to have a specific page be the home page, which is the role played by Main.WebHome. What I'm saying is that with the new system, I'd rather have *.../xwiki/bin/view/WebHome => **.../xwiki/bin/view/ *would be the whole wiki. That level would be the top level space (which is exactly what has been implemented by the way). Do you see what I mean?
Although we have a convention that a certain page is displayed as homepage, this is not needed to be in the URL. 'home' icon is a link for the homepage, not a physical location. Currently the 'Main' space can contain pages useful for the display of the homepage, but is an 'optional' space.
What I' suggesting is precisely that the home page be its own document at the very top of the hierarchy, ABOVE what is currently known as Main.WebHome. This is why while the user is on this page, she should see only the home icon.
Is this making what I mean clearer? I'm just suggesting we push things one step further in the direction that has already been established.
Thanks,
Guillaume
Thanks,
Caty
On Mon, Sep 14, 2015 at 11:25 AM, Guillaume Lerouge <[email protected]> wrote:
Hi Edy,
thanks for the explanation. Please see my feedback below.
On Fri, Sep 11, 2015 at 5:24 PM, Eduard Moraru <[email protected]> wrote:
Hi,
Yes, "this is not a bug, it's a feature!" :) I had documented it in a small paragraph [1] (see the note) but did not feel it was worthy to be mentioned in the release notes. Please feel free to rephrase if needed.
It's not specifically about "Main", but about the current wiki's homepage (and "Main.WebHome" is the default homepage that can be changed from administration).
Does this feature (changing the home page) still makes sense in the context of nested spaces? What is the point to define the home page as ".../A/B/C" when based on the new system, "C" is a sub-sub page?
To me, with nested spaces the home page is always the same and cannot be changed. You may want to add a redirect, but this doesn't change the fact that the top page is the same.
The effort is to try to avoid the situation where a regular user lands on the homepage of the wiki (just accessed the wiki or maybe he clicked the logo) and wants to create a document. He enters the title and presses "create". Obviously his intention was to create a page, and, more often than not (IMO at least), his actual intention was to create a top level document and not a child document of the wiki's current homepage.
I agree with this. However, in that case, shouldn't the home page be simply *https://<server>/xwiki/bin/view/* instead of *https://<server>/xwiki/bin/view/Main/* ?
Using short URLs, you could even have the home page under *https:// <server>/ *and then subpages at *https://<server>/A, **https://<server>/A/B* and so on. This would be in line with what most CMS do and it would fix your issue: any page created from the home is a sub-page at the expected level.
Image the homepage gets changed to "Some.Deep.Document.As.Homepage".
Without this "trick", a regular user would end up, by mistake IMO (and by using the "next-next-next" mindset), creating the document "Some.Deep.Document.As.Homepage.NewDocument".
As I said above, I actually think we should remove this feature in the context of nested spaces.
Even if the homepage remains the default one, I see no logical reason in spamming all the new documents with the "Main" prefix, the result being an artificially deeper hierarchy and longer URL.
Agreed. As mentioned above, ideally we'd remove it.
If a user really intended to create a document as a child of the homepage (rare usecase IMO), he has all the tools in the UI to simply do so.
I agree that it's a minor consistency dent, but IMO the benefit justifies it.
I don't quite agree that it's minor. One of the implied goals of nested spaces is to be able to have consistent URL naming (I know exactly where page *https://<server>/A/B/C *is). Having a special case for Main breaks this.
Similarly, when on the home page on the main wiki, I don't understand why the breadcrumb shows both the "home" icon and "Home" text. Why keep both when the icon would be enough?
Thanks,
Guillaume
WDYT? (interested in more opinions on this since I've already had 2
eyebrows raised on this topic :) )
Thanks, Eduard
--------- [1]
http://platform.xwiki.org/xwiki/bin/view/Features/DocumentLifecycle#HByusing...
On Fri, Sep 11, 2015 at 4:42 PM, Guillaume Lerouge <
wrote:
Hi Devs,
I started trying out XE 7.2 (SNAPSHOT from around 12:30 today) and I was very impressed, the changes look quite good!
While playing with it, I had a question about how the "Main" space is handled. Here's what I did: from .../xwiki/bin/view/Main/, I clicked the "create" button and created a sub page, then a sub-sub page. Here's what I got:
- .../xwiki/bin/view/SubPage/SubSubPage
Although I was expecting this:
- .../xwiki/bin/view/Main/SubPage/SubSubPage
So I was wondering whether this was the expected behavior, and whether it had been discussed before?
Congrats & Thanks,
Guillaume _______________________________________________ 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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Marius, On Tue, Sep 15, 2015 at 3:23 PM, Marius Dumitru Florea < [email protected]> wrote:
Hi Guillaume,
On Mon, Sep 14, 2015 at 6:26 PM, Guillaume Lerouge <[email protected]> wrote:
Hi Caty,
thanks for your message. Please see my answers below.
On Mon, Sep 14, 2015 at 11:22 AM, Ecaterina Moraru (Valica) < [email protected]> wrote:
Hi,
The current behavior was reached after many discussions.
I understand. However, I only got the time to actually try and test XE 7.2 last week. And based on what Edy said, I'm not the only one who was surprised by the current behavior :-)
Currently the concept of main wiki is expressed as the 'home' icon, but is not tied to a particular space. This is something we preserved and is flexible enough for users with custom content to change the location of the homepage or assigned a different space, for a different subwiki.
I understand this. I'm not questioning the current behavior, but the underlying assumption. Given the new paradigm we're implementing with nested spaces, why would an user want to change the location of the homepage? To me, it's like saying that you would want the top level folder on your computer to be something else than the hard drive itself. I don't understand why that would be useful.
The hard-drive is the wiki not the Main space. Or, if you want to be precise, the entire farm is the hard-drive, a wiki is a partition on that hard-drive and a space is a folder on a partition. The Main space is just one of the top level "folders". Blog, XWiki, Sandbox are also at the top level. And you can create new top level "folders". When you access XWiki you get redirected to the Main space by default but someone may want the Blog space to be opened by default.
Do you have specific use cases in mind that I might be missing (other
than
"this feature existed before")?
Also we needed to showcase differently spaces that are top level, vs. pages
inside the Main space, while having the limited number of exceptions created for the breadcrumb.
I think there are 2 separate problems here:
1. Where should we put all of the pages that are currently in the "Main" space if we decide that not all of them deserve to be top-level pages
Pages from the Main space are not top level. Main is top level, and Main is on the same level with Blog, Sandbox and XWiki. Check the document index tree. I have the feeling you're making a confusion.
I am making an intentional confusion because I think that this is how end-users are going to perceive it too. I think I understand well enough XWiki's current model, the reason why there's a Main space to begin with and the fact that it's just a space among others, not a top-level space by itself. However, we cannot expect that level of implicit knowledge from a fresh new user. As a new user, I'm on "Main", which to me is the top level page, I create a new page, and it's created next to Main, not under it. That doesn't fit with my mental model of how nested pages should work. That new page should be under Main, not at the same level. Do you see what I mean? As pointed out by Caty, I also understand that there are technical limitations that explain this behavior and that it's tough to overcome them in the short amount of time that we have as part of the 7.2 release timeframe. We'll most likely have to keep the current behavior and live with it for a while. But I know for sure that it is going to create confusion for some end users, the same way it did for me :-) Thanks, Guillaume
2. Making it possible to have top-level pages in a coherent manner
For 1., pages in the Main space could stay where they are for now. "Main" would be the legacy space where we put useful tools for the management of your wiki.
I'm discussing the answer for 2. below.
Also I wouldn't like that all the URL contain the word 'Main' Imagine
that
besides the 'xwiki/bin/view/' we would need to also contain the homepage space?
My very point is that the home page wouldn't (shouldn't?) need to be "Main". It would be "". IE, there would be nothing in the URL to reflect it. It would be a representation of the wiki itself.
I understand that technically this is not feasible right now and that we *need* to have a specific page be the home page, which is the role played by Main.WebHome. What I'm saying is that with the new system, I'd rather have *.../xwiki/bin/view/WebHome => **.../xwiki/bin/view/ *would be the whole wiki. That level would be the top level space (which is exactly what has been implemented by the way). Do you see what I mean?
Although we have a convention that a certain page is displayed as homepage, this is not needed to be in the URL. 'home' icon is a link for the homepage, not a physical location. Currently the 'Main' space can contain pages useful for the display of the homepage, but is an 'optional' space.
What I' suggesting is precisely that the home page be its own document at the very top of the hierarchy, ABOVE what is currently known as Main.WebHome. This is why while the user is on this page, she should see only the home icon.
Is this making what I mean clearer? I'm just suggesting we push things one step further in the direction that has already been established.
Thanks,
Guillaume
Thanks,
Caty
On Mon, Sep 14, 2015 at 11:25 AM, Guillaume Lerouge < [email protected]> wrote:
Hi Edy,
thanks for the explanation. Please see my feedback below.
On Fri, Sep 11, 2015 at 5:24 PM, Eduard Moraru <[email protected]> wrote:
Hi,
Yes, "this is not a bug, it's a feature!" :) I had documented it in a small paragraph [1] (see the note) but did not feel it was worthy to be mentioned in the release notes. Please feel free to rephrase if needed.
It's not specifically about "Main", but about the current wiki's homepage (and "Main.WebHome" is the default homepage that can be changed from administration).
Does this feature (changing the home page) still makes sense in the context of nested spaces? What is the point to define the home page as ".../A/B/C" when based on the new system, "C" is a sub-sub page?
To me, with nested spaces the home page is always the same and cannot be changed. You may want to add a redirect, but this doesn't change the fact that the top page is the same.
The effort is to try to avoid the situation where a regular user lands on the homepage of the wiki (just accessed the wiki or maybe he clicked the logo) and wants to create a document. He enters the title and presses "create". Obviously his intention was to create a page, and, more often than not (IMO at least), his actual intention was to create a top level document and not a child document of the wiki's current homepage.
I agree with this. However, in that case, shouldn't the home page be simply *https://<server>/xwiki/bin/view/* instead of *https://<server>/xwiki/bin/view/Main/* ?
Using short URLs, you could even have the home page under *https:// <server>/ *and then subpages at *https://<server>/A, **https://<server>/A/B* and so on. This would be in line with what most CMS do and it would fix your issue: any page created from the home is a sub-page at the expected level.
Image the homepage gets changed to "Some.Deep.Document.As.Homepage".
Without this "trick", a regular user would end up, by mistake IMO (and by using the "next-next-next" mindset), creating the document "Some.Deep.Document.As.Homepage.NewDocument".
As I said above, I actually think we should remove this feature in the context of nested spaces.
Even if the homepage remains the default one, I see no logical reason in spamming all the new documents with the "Main" prefix, the result being an artificially deeper hierarchy and longer URL.
Agreed. As mentioned above, ideally we'd remove it.
If a user really intended to create a document as a child of the homepage (rare usecase IMO), he has all the tools in the UI to simply do so.
I agree that it's a minor consistency dent, but IMO the benefit justifies it.
I don't quite agree that it's minor. One of the implied goals of nested spaces is to be able to have consistent URL naming (I know exactly where page *https://<server>/A/B/C *is). Having a special case for Main breaks this.
Similarly, when on the home page on the main wiki, I don't understand why the breadcrumb shows both the "home" icon and "Home" text. Why keep both when the icon would be enough?
Thanks,
Guillaume
WDYT? (interested in more opinions on this since I've already had 2
eyebrows raised on this topic :) )
Thanks, Eduard
--------- [1]
http://platform.xwiki.org/xwiki/bin/view/Features/DocumentLifecycle#HByusing...
On Fri, Sep 11, 2015 at 4:42 PM, Guillaume Lerouge <
wrote:
Hi Devs,
I started trying out XE 7.2 (SNAPSHOT from around 12:30 today) and I was very impressed, the changes look quite good!
While playing with it, I had a question about how the "Main" space is handled. Here's what I did: from .../xwiki/bin/view/Main/, I clicked the "create" button and created a sub page, then a sub-sub page. Here's what I got:
- .../xwiki/bin/view/SubPage/SubSubPage
Although I was expecting this:
- .../xwiki/bin/view/Main/SubPage/SubSubPage
So I was wondering whether this was the expected behavior, and whether it had been discussed before?
Congrats & Thanks,
Guillaume
Hi Guillaume, You propose a single top level/root document, but no top level space. How does that fit into XWiki`s model? What is the reference of this root document? "xwiki:.WebHome", "xwiki:.", ? How do we interact with it? Also, is a random xwiki:Space.Page document supposed to be a child of this implicit root document? What we currently do is that we have the Main Wiki > Current Wiki > Top Level Document > Child Document > Child Document hierarchy. The link to "Current Wiki" goes to whatever the homepage is configured to be. This does not mean that the linked document is the parent of "Top Level Document". The parent of "Top Level Document" is the wiki "Current Wiki". The homepage of that wiki may be different, but that does not make the homepage document a parent of the "Top Level Document". If you consider the homepage of the wiki as the parent of top level documents, you will end up creating pages in the "Blog" space, as Marius exemplified above, because the wiki admin wanted the "Blog" spaces (Nested Document) to be the homepage for his personalized wiki. We want to allow more configuration in contrast to requiring more code/content change (which would be the alternative when enforcing a fixed homepage document). I`m trying to focus more on the actual impact of this, since IMO it's better to make a slight effort in understanding why something happens and, once understood, you either agree with it or live with it, but in both cases you don`t suffer from the side effect caused by a possible solution that would be easier to understand but had an unwanted effect. I`m curious how this turns out in practice. Thanks, Eduard On Tue, Sep 15, 2015 at 5:30 PM, Guillaume Lerouge <[email protected]> wrote:
Hi Marius,
On Tue, Sep 15, 2015 at 3:23 PM, Marius Dumitru Florea < [email protected]> wrote:
Hi Guillaume,
On Mon, Sep 14, 2015 at 6:26 PM, Guillaume Lerouge <[email protected]> wrote:
Hi Caty,
thanks for your message. Please see my answers below.
On Mon, Sep 14, 2015 at 11:22 AM, Ecaterina Moraru (Valica) < [email protected]> wrote:
Hi,
The current behavior was reached after many discussions.
I understand. However, I only got the time to actually try and test XE 7.2 last week. And based on what Edy said, I'm not the only one who was surprised by the current behavior :-)
Currently the concept of main wiki is expressed as the 'home' icon, but is not tied to a particular space. This is something we preserved and is flexible enough for users with custom content to change the location of the homepage or assigned a different space, for a different subwiki.
I understand this. I'm not questioning the current behavior, but the underlying assumption. Given the new paradigm we're implementing with nested spaces, why would an user want to change the location of the homepage? To me, it's like saying that you would want the top level folder on your computer to be something else than the hard drive itself. I don't understand why that would be useful.
The hard-drive is the wiki not the Main space. Or, if you want to be precise, the entire farm is the hard-drive, a wiki is a partition on that hard-drive and a space is a folder on a partition. The Main space is just one of the top level "folders". Blog, XWiki, Sandbox are also at the top level. And you can create new top level "folders". When you access XWiki you get redirected to the Main space by default but someone may want the Blog space to be opened by default.
Do you have specific use cases in mind that I might be missing (other
than
"this feature existed before")?
Also we needed to showcase differently spaces that are top level, vs. pages
inside the Main space, while having the limited number of exceptions created for the breadcrumb.
I think there are 2 separate problems here:
1. Where should we put all of the pages that are currently in the "Main" space if we decide that not all of them deserve to be top-level pages
Pages from the Main space are not top level. Main is top level, and Main is on the same level with Blog, Sandbox and XWiki. Check the document index tree. I have the feeling you're making a confusion.
I am making an intentional confusion because I think that this is how end-users are going to perceive it too. I think I understand well enough XWiki's current model, the reason why there's a Main space to begin with and the fact that it's just a space among others, not a top-level space by itself.
However, we cannot expect that level of implicit knowledge from a fresh new user. As a new user, I'm on "Main", which to me is the top level page, I create a new page, and it's created next to Main, not under it. That doesn't fit with my mental model of how nested pages should work. That new page should be under Main, not at the same level. Do you see what I mean?
As pointed out by Caty, I also understand that there are technical limitations that explain this behavior and that it's tough to overcome them in the short amount of time that we have as part of the 7.2 release timeframe. We'll most likely have to keep the current behavior and live with it for a while. But I know for sure that it is going to create confusion for some end users, the same way it did for me :-)
Thanks,
Guillaume
2. Making it possible to have top-level pages in a coherent manner
For 1., pages in the Main space could stay where they are for now.
"Main"
would be the legacy space where we put useful tools for the management of your wiki.
I'm discussing the answer for 2. below.
Also I wouldn't like that all the URL contain the word 'Main' Imagine that
besides the 'xwiki/bin/view/' we would need to also contain the homepage space?
My very point is that the home page wouldn't (shouldn't?) need to be "Main". It would be "". IE, there would be nothing in the URL to reflect it. It would be a representation of the wiki itself.
I understand that technically this is not feasible right now and that we *need* to have a specific page be the home page, which is the role played by Main.WebHome. What I'm saying is that with the new system, I'd rather have *.../xwiki/bin/view/WebHome => **.../xwiki/bin/view/ *would be the whole wiki. That level would be the top level space (which is exactly what has been implemented by the way). Do you see what I mean?
Although we have a convention that a certain page is displayed as homepage, this is not needed to be in the URL. 'home' icon is a link for the homepage, not a physical location. Currently the 'Main' space can contain pages useful for the display of the homepage, but is an 'optional' space.
What I' suggesting is precisely that the home page be its own document at the very top of the hierarchy, ABOVE what is currently known as Main.WebHome. This is why while the user is on this page, she should see only the home icon.
Is this making what I mean clearer? I'm just suggesting we push things one step further in the direction that has already been established.
Thanks,
Guillaume
Thanks,
Caty
On Mon, Sep 14, 2015 at 11:25 AM, Guillaume Lerouge < [email protected]> wrote:
Hi Edy,
thanks for the explanation. Please see my feedback below.
On Fri, Sep 11, 2015 at 5:24 PM, Eduard Moraru < [email protected]> wrote:
Hi,
Yes, "this is not a bug, it's a feature!" :) I had documented it in a small paragraph [1] (see the note) but did not feel it was worthy to be mentioned in the release notes. Please feel free to rephrase if needed.
It's not specifically about "Main", but about the current wiki's homepage (and "Main.WebHome" is the default homepage that can be changed from administration).
Does this feature (changing the home page) still makes sense in the context of nested spaces? What is the point to define the home page as ".../A/B/C" when based on the new system, "C" is a sub-sub page?
To me, with nested spaces the home page is always the same and cannot be changed. You may want to add a redirect, but this doesn't change the fact that the top page is the same.
The effort is to try to avoid the situation where a regular user lands on the homepage of the wiki (just accessed the wiki or maybe he clicked the logo) and wants to create a document. He enters the title and presses "create". Obviously his intention was to create a page, and, more often than not (IMO at least), his actual intention was to create a top level document and not a child document of the wiki's current homepage.
I agree with this. However, in that case, shouldn't the home page be simply *https://<server>/xwiki/bin/view/* instead of *https://<server>/xwiki/bin/view/Main/* ?
Using short URLs, you could even have the home page under *https:// <server>/ *and then subpages at *https://<server>/A, **https://<server>/A/B* and so on. This would be in line with what most CMS do and it would fix your issue: any page created from the home is a sub-page at the expected level.
Image the homepage gets changed to "Some.Deep.Document.As.Homepage".
Without this "trick", a regular user would end up, by mistake IMO (and by using the "next-next-next" mindset), creating the document "Some.Deep.Document.As.Homepage.NewDocument".
As I said above, I actually think we should remove this feature in the context of nested spaces.
Even if the homepage remains the default one, I see no logical reason in spamming all the new documents with the "Main" prefix, the result being an artificially deeper hierarchy and longer URL.
Agreed. As mentioned above, ideally we'd remove it.
If a user really intended to create a document as a child of the homepage (rare usecase IMO), he has all the tools in the UI to simply do so.
I agree that it's a minor consistency dent, but IMO the benefit justifies it.
I don't quite agree that it's minor. One of the implied goals of nested spaces is to be able to have consistent URL naming (I know exactly where page *https://<server>/A/B/C *is). Having a special case for Main breaks this.
Similarly, when on the home page on the main wiki, I don't understand why the breadcrumb shows both the "home" icon and "Home" text. Why keep both when the icon would be enough?
Thanks,
Guillaume
WDYT? (interested in more opinions on this since I've already had 2
eyebrows raised on this topic :) )
Thanks, Eduard
--------- [1]
http://platform.xwiki.org/xwiki/bin/view/Features/DocumentLifecycle#HByusing...
On Fri, Sep 11, 2015 at 4:42 PM, Guillaume Lerouge <
wrote:
> Hi Devs, > > I started trying out XE 7.2 (SNAPSHOT from around 12:30 today) and I was > very impressed, the changes look quite good! > > While playing with it, I had a question about how the "Main" space is > handled. Here's what I did: from .../xwiki/bin/view/Main/, I clicked the > "create" button and created a sub page, then a sub-sub page. Here's what I > got: > > - .../xwiki/bin/view/SubPage/SubSubPage > > Although I was expecting this: > > - .../xwiki/bin/view/Main/SubPage/SubSubPage > > So I was wondering whether this was the expected behavior, and whether it > had been discussed before? > > Congrats & Thanks, > > Guillaume
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Edy, On Tue, Sep 15, 2015 at 5:10 PM, Eduard Moraru <[email protected]> wrote:
Hi Guillaume,
You propose a single top level/root document, but no top level space. How does that fit into XWiki`s model? What is the reference of this root document? "xwiki:.WebHome", "xwiki:.", ? How do we interact with it? Also, is a random xwiki:Space.Page document supposed to be a child of this implicit root document?
Indeed, I'm probably (widely!) underestimating the amount of work needed to make something like this work and the impact. The reference of the "top homepage" would indeed have to be something like "xwiki:." (or even just "[[]]"!).
What we currently do is that we have the Main Wiki > Current Wiki > Top Level Document > Child Document > Child Document hierarchy. The link to "Current Wiki" goes to whatever the homepage is configured to be. This does not mean that the linked document is the parent of "Top Level Document". The parent of "Top Level Document" is the wiki "Current Wiki". The homepage of that wiki may be different, but that does not make the homepage document a parent of the "Top Level Document".
Actually you have 2 hierarchies, not one: - Main Wiki > Top Level Document in the main wiki > Child Document > Child Document hierarchy - Main Wiki > Sub-Wiki > Top Level Document > Child Document > Child Document hierarchy Which means that there are 2 different types of entities that can live under "Main Wiki" => it feels to me like a bit of a consistency issue, but we can't really avoid it at the moment.
If you consider the homepage of the wiki as the parent of top level documents, you will end up creating pages in the "Blog" space, as Marius exemplified above, because the wiki admin wanted the "Blog" spaces (Nested Document) to be the homepage for his personalized wiki.
No, since my point of view on this is that we shouldn't even allow the home page to be changed to begin with :-)
We want to allow more configuration in contrast to requiring more code/content change (which would be the alternative when enforcing a fixed homepage document).
Why is that? Why not keep the homepage where it is and let the user put a {{display}} macro there if needed? I don't really understand the rationale behind this. Changing the content of the homepage it very easy (one click on the "Edit" button)... I`m trying to focus more on the actual impact of this, since IMO it's
better to make a slight effort in understanding why something happens and, once understood, you either agree with it or live with it, but in both cases you don`t suffer from the side effect caused by a possible solution that would be easier to understand but had an unwanted effect.
Actually the current behavior suits me well overall. The only gripe I have is with the special treatment when creating pages from the home page. You can see even see it: when you click on the create button from the home, first the parent displays "Home" then you have a quick flickering as it gets hidden in Javascript... Now I understand that it's better to start with less changes and add things only as needed. We'll see how things goes.
I`m curious how this turns out in practice.
So am I! I guess we'll see when additional user feedback start coming in :-) Best, Guillaume
Thanks, Eduard
On Tue, Sep 15, 2015 at 5:30 PM, Guillaume Lerouge <[email protected]> wrote:
Hi Marius,
On Tue, Sep 15, 2015 at 3:23 PM, Marius Dumitru Florea < [email protected]> wrote:
Hi Guillaume,
On Mon, Sep 14, 2015 at 6:26 PM, Guillaume Lerouge < [email protected]> wrote:
Hi Caty,
thanks for your message. Please see my answers below.
On Mon, Sep 14, 2015 at 11:22 AM, Ecaterina Moraru (Valica) < [email protected]> wrote:
Hi,
The current behavior was reached after many discussions.
I understand. However, I only got the time to actually try and test XE 7.2 last week. And based on what Edy said, I'm not the only one who was surprised by the current behavior :-)
Currently the concept of main wiki is expressed as the 'home' icon, but is not tied to a particular space. This is something we preserved and is flexible enough for users with custom content to change the location of the homepage or assigned a different space, for a different subwiki.
I understand this. I'm not questioning the current behavior, but the underlying assumption. Given the new paradigm we're implementing with nested spaces, why would an user want to change the location of the homepage? To me, it's like saying that you would want the top level folder on your computer to be something else than the hard drive itself. I don't understand why that would be useful.
The hard-drive is the wiki not the Main space. Or, if you want to be precise, the entire farm is the hard-drive, a wiki is a partition on that hard-drive and a space is a folder on a partition. The Main space is just one of the top level "folders". Blog, XWiki, Sandbox are also at the top level. And you can create new top level "folders". When you access XWiki you get redirected to the Main space by default but someone may want the Blog space to be opened by default.
Do you have specific use cases in mind that I might be missing (other
than
"this feature existed before")?
Also we needed to showcase differently spaces that are top level, vs. pages
inside the Main space, while having the limited number of exceptions created for the breadcrumb.
I think there are 2 separate problems here:
1. Where should we put all of the pages that are currently in the "Main" space if we decide that not all of them deserve to be top-level pages
Pages from the Main space are not top level. Main is top level, and Main is on the same level with Blog, Sandbox and XWiki. Check the document index tree. I have the feeling you're making a confusion.
I am making an intentional confusion because I think that this is how end-users are going to perceive it too. I think I understand well enough XWiki's current model, the reason why there's a Main space to begin with and the fact that it's just a space among others, not a top-level space by itself.
However, we cannot expect that level of implicit knowledge from a fresh new user. As a new user, I'm on "Main", which to me is the top level page, I create a new page, and it's created next to Main, not under it. That doesn't fit with my mental model of how nested pages should work. That new page should be under Main, not at the same level. Do you see what I mean?
As pointed out by Caty, I also understand that there are technical limitations that explain this behavior and that it's tough to overcome them in the short amount of time that we have as part of the 7.2 release timeframe. We'll most likely have to keep the current behavior and live with it for a while. But I know for sure that it is going to create confusion for some end users, the same way it did for me :-)
Thanks,
Guillaume
2. Making it possible to have top-level pages in a coherent manner
For 1., pages in the Main space could stay where they are for now.
"Main"
would be the legacy space where we put useful tools for the management of your wiki.
I'm discussing the answer for 2. below.
Also I wouldn't like that all the URL contain the word 'Main' Imagine that
besides the 'xwiki/bin/view/' we would need to also contain the homepage space?
My very point is that the home page wouldn't (shouldn't?) need to be "Main". It would be "". IE, there would be nothing in the URL to reflect it. It would be a representation of the wiki itself.
I understand that technically this is not feasible right now and that we *need* to have a specific page be the home page, which is the role played by Main.WebHome. What I'm saying is that with the new system, I'd rather have *.../xwiki/bin/view/WebHome => **.../xwiki/bin/view/ *would be the whole wiki. That level would be the top level space (which is exactly what has been implemented by the way). Do you see what I mean?
Although we have a convention that a certain page is displayed as homepage, this is not needed to be in the URL. 'home' icon is a link for the homepage, not a physical location. Currently the 'Main' space can contain pages useful for the display of the homepage, but is an 'optional' space.
What I' suggesting is precisely that the home page be its own document at the very top of the hierarchy, ABOVE what is currently known as Main.WebHome. This is why while the user is on this page, she should see only the home icon.
Is this making what I mean clearer? I'm just suggesting we push things one step further in the direction that has already been established.
Thanks,
Guillaume
Thanks,
Caty
On Mon, Sep 14, 2015 at 11:25 AM, Guillaume Lerouge < [email protected]> wrote:
Hi Edy,
thanks for the explanation. Please see my feedback below.
On Fri, Sep 11, 2015 at 5:24 PM, Eduard Moraru < [email protected]> wrote:
> Hi, > > Yes, "this is not a bug, it's a feature!" :) I had documented it in a small > paragraph [1] (see the note) but did not feel it was worthy to be mentioned > in the release notes. Please feel free to rephrase if needed. > > It's not specifically about "Main", but about the current wiki's homepage > (and "Main.WebHome" is the default homepage that can be changed from > administration). >
Does this feature (changing the home page) still makes sense in the context of nested spaces? What is the point to define the home page as ".../A/B/C" when based on the new system, "C" is a sub-sub page?
To me, with nested spaces the home page is always the same and cannot be changed. You may want to add a redirect, but this doesn't change the fact that the top page is the same.
> The effort is to try to avoid the situation where a regular user lands on > the homepage of the wiki (just accessed the wiki or maybe he clicked the > logo) and wants to create a document. He enters the title and presses > "create". Obviously his intention was to create a page, and, more often > than not (IMO at least), his actual intention was to create a top level > document and not a child document of the wiki's current homepage. >
I agree with this. However, in that case, shouldn't the home page be simply *https://<server>/xwiki/bin/view/* instead of *https://<server>/xwiki/bin/view/Main/* ?
Using short URLs, you could even have the home page under *https:// <server>/ *and then subpages at *https://<server>/A, **https:// <server>/A/B* and so on. This would be in line with what most CMS do and it would fix your issue: any page created from the home is a sub-page at the expected level.
Image the homepage gets changed to "Some.Deep.Document.As.Homepage". > Without this "trick", a regular user would end up, by mistake IMO (and by > using the "next-next-next" mindset), creating the document > "Some.Deep.Document.As.Homepage.NewDocument". >
As I said above, I actually think we should remove this feature in the context of nested spaces.
> Even if the homepage remains the default one, I see no logical reason in > spamming all the new documents with the "Main" prefix, the result being an > artificially deeper hierarchy and longer URL. >
Agreed. As mentioned above, ideally we'd remove it.
> If a user really intended to create a document as a child of the homepage > (rare usecase IMO), he has all the tools in the UI to simply do so. > > I agree that it's a minor consistency dent, but IMO the benefit justifies > it. >
I don't quite agree that it's minor. One of the implied goals of nested spaces is to be able to have consistent URL naming (I know exactly where page *https://<server>/A/B/C *is). Having a special case for Main breaks this.
Similarly, when on the home page on the main wiki, I don't understand why the breadcrumb shows both the "home" icon and "Home" text. Why keep both when the icon would be enough?
Thanks,
Guillaume
WDYT? (interested in more opinions on this since I've already had 2 > eyebrows raised on this topic :) ) > > Thanks, > Eduard > > --------- > [1] > >
http://platform.xwiki.org/xwiki/bin/view/Features/DocumentLifecycle#HByusing...
> > On Fri, Sep 11, 2015 at 4:42 PM, Guillaume Lerouge < [email protected]> > wrote: > > > Hi Devs, > > > > I started trying out XE 7.2 (SNAPSHOT from around 12:30 today) and I was > > very impressed, the changes look quite good! > > > > While playing with it, I had a question about how the "Main" space is > > handled. Here's what I did: from .../xwiki/bin/view/Main/, I clicked the > > "create" button and created a sub page, then a sub-sub page. Here's what > I > > got: > > > > - .../xwiki/bin/view/SubPage/SubSubPage > > > > Although I was expecting this: > > > > - .../xwiki/bin/view/Main/SubPage/SubSubPage > > > > So I was wondering whether this was the expected behavior, and whether it > > had been discussed before? > > > > Congrats & Thanks, > > > > Guillaume
On Thu, Sep 17, 2015 at 12:46 PM, Guillaume Lerouge <[email protected]> wrote:
Hi Edy,
On Tue, Sep 15, 2015 at 5:10 PM, Eduard Moraru <[email protected]> wrote:
Hi Guillaume,
You propose a single top level/root document, but no top level space. How does that fit into XWiki`s model? What is the reference of this root document? "xwiki:.WebHome", "xwiki:.", ? How do we interact with it? Also, is a random xwiki:Space.Page document supposed to be a child of this implicit root document?
Indeed, I'm probably (widely!) underestimating the amount of work needed to make something like this work and the impact. The reference of the "top homepage" would indeed have to be something like "xwiki:." (or even just "[[]]"!).
What we currently do is that we have the Main Wiki > Current Wiki > Top Level Document > Child Document > Child Document hierarchy. The link to "Current Wiki" goes to whatever the homepage is configured to be. This does not mean that the linked document is the parent of "Top Level Document". The parent of "Top Level Document" is the wiki "Current Wiki". The homepage of that wiki may be different, but that does not make the homepage document a parent of the "Top Level Document".
Actually you have 2 hierarchies, not one:
- Main Wiki > Top Level Document in the main wiki > Child Document > Child Document hierarchy - Main Wiki > Sub-Wiki > Top Level Document > Child Document > Child Document hierarchy
Which means that there are 2 different types of entities that can live under "Main Wiki" => it feels to me like a bit of a consistency issue, but we can't really avoid it at the moment.
If you consider the homepage of the wiki as the parent of top level documents, you will end up creating pages in the "Blog" space, as Marius exemplified above, because the wiki admin wanted the "Blog" spaces (Nested Document) to be the homepage for his personalized wiki.
No, since my point of view on this is that we shouldn't even allow the home page to be changed to begin with :-)
We want to allow more configuration in contrast to requiring more code/content change (which would be the alternative when enforcing a fixed homepage document).
Why is that? Why not keep the homepage where it is and let the user put a {{display}} macro there if needed? I don't really understand the rationale behind this. Changing the content of the homepage it very easy (one click on the "Edit" button)...
The upgrade could become a bit more complex if you modify the default home page.
I`m trying to focus more on the actual impact of this, since IMO it's
better to make a slight effort in understanding why something happens and, once understood, you either agree with it or live with it, but in both cases you don`t suffer from the side effect caused by a possible solution that would be easier to understand but had an unwanted effect.
Actually the current behavior suits me well overall. The only gripe I have is with the special treatment when creating pages from the home page. You can see even see it: when you click on the create button from the home, first the parent displays "Home" then you have a quick flickering as it gets hidden in Javascript...
Now I understand that it's better to start with less changes and add things only as needed. We'll see how things goes.
I`m curious how this turns out in practice.
So am I! I guess we'll see when additional user feedback start coming in :-)
Best,
Guillaume
Thanks, Eduard
On Tue, Sep 15, 2015 at 5:30 PM, Guillaume Lerouge <[email protected]> wrote:
Hi Marius,
On Tue, Sep 15, 2015 at 3:23 PM, Marius Dumitru Florea < [email protected]> wrote:
Hi Guillaume,
On Mon, Sep 14, 2015 at 6:26 PM, Guillaume Lerouge < [email protected]> wrote:
Hi Caty,
thanks for your message. Please see my answers below.
On Mon, Sep 14, 2015 at 11:22 AM, Ecaterina Moraru (Valica) < [email protected]> wrote:
Hi,
The current behavior was reached after many discussions.
I understand. However, I only got the time to actually try and test XE 7.2 last week. And based on what Edy said, I'm not the only one who was surprised by the current behavior :-)
Currently the concept of main wiki is expressed as the 'home' icon, but is not tied to a particular space. This is something we preserved and is flexible enough for users with custom content to change the location of the homepage or assigned a different space, for a different subwiki.
I understand this. I'm not questioning the current behavior, but the underlying assumption. Given the new paradigm we're implementing with nested spaces, why would an user want to change the location of the homepage? To me, it's like saying that you would want the top level folder on your computer to be something else than the hard drive itself. I don't understand why that would be useful.
The hard-drive is the wiki not the Main space. Or, if you want to be precise, the entire farm is the hard-drive, a wiki is a partition on that hard-drive and a space is a folder on a partition. The Main space is just one of the top level "folders". Blog, XWiki, Sandbox are also at the top level. And you can create new top level "folders". When you access XWiki you get redirected to the Main space by default but someone may want the Blog space to be opened by default.
Do you have specific use cases in mind that I might be missing (other
than
"this feature existed before")?
Also we needed to showcase differently spaces that are top level, vs. pages
inside the Main space, while having the limited number of exceptions created for the breadcrumb.
I think there are 2 separate problems here:
1. Where should we put all of the pages that are currently in the "Main" space if we decide that not all of them deserve to be top-level pages
Pages from the Main space are not top level. Main is top level, and Main is on the same level with Blog, Sandbox and XWiki. Check the document index tree. I have the feeling you're making a confusion.
I am making an intentional confusion because I think that this is how end-users are going to perceive it too. I think I understand well enough XWiki's current model, the reason why there's a Main space to begin with and the fact that it's just a space among others, not a top-level space by itself.
However, we cannot expect that level of implicit knowledge from a fresh new user. As a new user, I'm on "Main", which to me is the top level page, I create a new page, and it's created next to Main, not under it. That doesn't fit with my mental model of how nested pages should work. That new page should be under Main, not at the same level. Do you see what I mean?
As pointed out by Caty, I also understand that there are technical limitations that explain this behavior and that it's tough to overcome them in the short amount of time that we have as part of the 7.2 release timeframe. We'll most likely have to keep the current behavior and live with it for a while. But I know for sure that it is going to create confusion for some end users, the same way it did for me :-)
Thanks,
Guillaume
2. Making it possible to have top-level pages in a coherent manner
For 1., pages in the Main space could stay where they are for now.
"Main"
would be the legacy space where we put useful tools for the management of your wiki.
I'm discussing the answer for 2. below.
Also I wouldn't like that all the URL contain the word 'Main' Imagine that
besides the 'xwiki/bin/view/' we would need to also contain the homepage space?
My very point is that the home page wouldn't (shouldn't?) need to be "Main". It would be "". IE, there would be nothing in the URL to reflect it. It would be a representation of the wiki itself.
I understand that technically this is not feasible right now and that we *need* to have a specific page be the home page, which is the role played by Main.WebHome. What I'm saying is that with the new system, I'd rather have *.../xwiki/bin/view/WebHome => **.../xwiki/bin/view/ *would be the whole wiki. That level would be the top level space (which is exactly what has been implemented by the way). Do you see what I mean?
Although we have a convention that a certain page is displayed as homepage, this is not needed to be in the URL. 'home' icon is a link for the homepage, not a physical location. Currently the 'Main' space can contain pages useful for the display of the homepage, but is an 'optional' space.
What I' suggesting is precisely that the home page be its own document at the very top of the hierarchy, ABOVE what is currently known as Main.WebHome. This is why while the user is on this page, she should see only the home icon.
Is this making what I mean clearer? I'm just suggesting we push things one step further in the direction that has already been established.
Thanks,
Guillaume
Thanks,
Caty
On Mon, Sep 14, 2015 at 11:25 AM, Guillaume Lerouge < [email protected]> wrote:
> Hi Edy, > > thanks for the explanation. Please see my feedback below. > > On Fri, Sep 11, 2015 at 5:24 PM, Eduard Moraru < [email protected]> > wrote: > > > Hi, > > > > Yes, "this is not a bug, it's a feature!" :) I had documented it in a > small > > paragraph [1] (see the note) but did not feel it was worthy to be > mentioned > > in the release notes. Please feel free to rephrase if needed. > > > > It's not specifically about "Main", but about the current wiki's homepage > > (and "Main.WebHome" is the default homepage that can be changed from > > administration). > > > > Does this feature (changing the home page) still makes sense in the context > of nested spaces? What is the point to define the home page as ".../A/B/C" > when based on the new system, "C" is a sub-sub page? > > To me, with nested spaces the home page is always the same and cannot be > changed. You may want to add a redirect, but this doesn't change the fact > that the top page is the same. > > > > The effort is to try to avoid the situation where a regular user lands on > > the homepage of the wiki (just accessed the wiki or maybe he clicked the > > logo) and wants to create a document. He enters the title and presses > > "create". Obviously his intention was to create a page, and, more often > > than not (IMO at least), his actual intention was to create a top level > > document and not a child document of the wiki's current homepage. > > > > I agree with this. However, in that case, shouldn't the home page be simply > *https://<server>/xwiki/bin/view/* instead of > *https://<server>/xwiki/bin/view/Main/* ? > > Using short URLs, you could even have the home page under *https:// > <server>/ > *and then subpages at *https://<server>/A, **https:// <server>/A/B* and so > on. This would be in line with what most CMS do and it would fix your > issue: any page created from the home is a sub-page at the expected level. > > Image the homepage gets changed to "Some.Deep.Document.As.Homepage". > > Without this "trick", a regular user would end up, by mistake IMO (and by > > using the "next-next-next" mindset), creating the document > > "Some.Deep.Document.As.Homepage.NewDocument". > > > > As I said above, I actually think we should remove this feature in the > context of nested spaces. > > > > Even if the homepage remains the default one, I see no logical reason in > > spamming all the new documents with the "Main" prefix, the result being > an > > artificially deeper hierarchy and longer URL. > > > > Agreed. As mentioned above, ideally we'd remove it. > > > > If a user really intended to create a document as a child of the homepage > > (rare usecase IMO), he has all the tools in the UI to simply do so. > > > > I agree that it's a minor consistency dent, but IMO the benefit justifies > > it. > > > > I don't quite agree that it's minor. One of the implied goals of nested > spaces is to be able to have consistent URL naming (I know exactly where > page *https://<server>/A/B/C *is). Having a special case for Main breaks > this. > > Similarly, when on the home page on the main wiki, I don't understand why > the breadcrumb shows both the "home" icon and "Home" text. Why keep both > when the icon would be enough? > > Thanks, > > Guillaume > > WDYT? (interested in more opinions on this since I've already had 2 > > eyebrows raised on this topic :) ) > > > > Thanks, > > Eduard > > > > --------- > > [1] > > > > >
http://platform.xwiki.org/xwiki/bin/view/Features/DocumentLifecycle#HByusing...
> > > > On Fri, Sep 11, 2015 at 4:42 PM, Guillaume Lerouge < [email protected]> > > wrote: > > > > > Hi Devs, > > > > > > I started trying out XE 7.2 (SNAPSHOT from around 12:30 today) and I > was > > > very impressed, the changes look quite good! > > > > > > While playing with it, I had a question about how the "Main" space is > > > handled. Here's what I did: from .../xwiki/bin/view/Main/, I clicked > the > > > "create" button and created a sub page, then a sub-sub page. Here's > what > > I > > > got: > > > > > > - .../xwiki/bin/view/SubPage/SubSubPage > > > > > > Although I was expecting this: > > > > > > - .../xwiki/bin/view/Main/SubPage/SubSubPage > > > > > > So I was wondering whether this was the expected behavior, and whether > it > > > had been discussed before? > > > > > > Congrats & Thanks, > > > > > > Guillaume
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Thu, Sep 17, 2015 at 12:46 PM, Guillaume Lerouge <[email protected]> wrote:
Hi Edy,
On Tue, Sep 15, 2015 at 5:10 PM, Eduard Moraru <[email protected]> wrote:
Hi Guillaume,
You propose a single top level/root document, but no top level space. How does that fit into XWiki`s model? What is the reference of this root document? "xwiki:.WebHome", "xwiki:.", ? How do we interact with it? Also, is a random xwiki:Space.Page document supposed to be a child of this implicit root document?
Indeed, I'm probably (widely!) underestimating the amount of work needed to make something like this work and the impact. The reference of the "top homepage" would indeed have to be something like "xwiki:." (or even just "[[]]"!).
What we currently do is that we have the Main Wiki > Current Wiki > Top Level Document > Child Document > Child Document hierarchy. The link to "Current Wiki" goes to whatever the homepage is configured to be. This does not mean that the linked document is the parent of "Top Level Document". The parent of "Top Level Document" is the wiki "Current Wiki". The homepage of that wiki may be different, but that does not make the homepage document a parent of the "Top Level Document".
Actually you have 2 hierarchies, not one:
- Main Wiki > Top Level Document in the main wiki > Child Document > Child Document hierarchy - Main Wiki > Sub-Wiki > Top Level Document > Child Document > Child Document hierarchy
Which means that there are 2 different types of entities that can live under "Main Wiki" => it feels to me like a bit of a consistency issue, but we can't really avoid it at the moment.
If you consider the homepage of the wiki as the parent of top level documents, you will end up creating pages in the "Blog" space, as Marius exemplified above, because the wiki admin wanted the "Blog" spaces (Nested Document) to be the homepage for his personalized wiki.
No, since my point of view on this is that we shouldn't even allow the home page to be changed to begin with :-)
We want to allow more configuration in contrast to requiring more code/content change (which would be the alternative when enforcing a fixed homepage document).
Why is that? Why not keep the homepage where it is and let the user put a {{display}} macro there if needed? I don't really understand the rationale behind this. Changing the content of the homepage it very easy (one click on the "Edit" button)...
I`m trying to focus more on the actual impact of this, since IMO it's
better to make a slight effort in understanding why something happens and, once understood, you either agree with it or live with it, but in both cases you don`t suffer from the side effect caused by a possible solution that would be easier to understand but had an unwanted effect.
Actually the current behavior suits me well overall. The only gripe I have is with the special treatment when creating pages from the home page. You can see even see it: when you click on the create button from the home, first the parent displays "Home" then you have a quick flickering as it gets hidden in Javascript...
Yes, that was a bug caused by a limitation of the initial implementation. It`s now fixed by http://jira.xwiki.org/browse/XWIKI-12592 and will be included in the 7.2 final release. Thanks, Eduard
Now I understand that it's better to start with less changes and add things only as needed. We'll see how things goes.
I`m curious how this turns out in practice.
So am I! I guess we'll see when additional user feedback start coming in :-)
Best,
Guillaume
Thanks, Eduard
On Tue, Sep 15, 2015 at 5:30 PM, Guillaume Lerouge <[email protected]> wrote:
Hi Marius,
On Tue, Sep 15, 2015 at 3:23 PM, Marius Dumitru Florea < [email protected]> wrote:
Hi Guillaume,
On Mon, Sep 14, 2015 at 6:26 PM, Guillaume Lerouge < [email protected]> wrote:
Hi Caty,
thanks for your message. Please see my answers below.
On Mon, Sep 14, 2015 at 11:22 AM, Ecaterina Moraru (Valica) < [email protected]> wrote:
Hi,
The current behavior was reached after many discussions.
I understand. However, I only got the time to actually try and test XE 7.2 last week. And based on what Edy said, I'm not the only one who was surprised by the current behavior :-)
Currently the concept of main wiki is expressed as the 'home' icon, but is not tied to a particular space. This is something we preserved and is flexible enough for users with custom content to change the location of the homepage or assigned a different space, for a different subwiki.
I understand this. I'm not questioning the current behavior, but the underlying assumption. Given the new paradigm we're implementing with nested spaces, why would an user want to change the location of the homepage? To me, it's like saying that you would want the top level folder on your computer to be something else than the hard drive itself. I don't understand why that would be useful.
The hard-drive is the wiki not the Main space. Or, if you want to be precise, the entire farm is the hard-drive, a wiki is a partition on that hard-drive and a space is a folder on a partition. The Main space is just one of the top level "folders". Blog, XWiki, Sandbox are also at the top level. And you can create new top level "folders". When you access XWiki you get redirected to the Main space by default but someone may want the Blog space to be opened by default.
Do you have specific use cases in mind that I might be missing
(other than
"this feature existed before")?
Also we needed to showcase differently spaces that are top level, vs. pages
inside the Main space, while having the limited number of exceptions created for the breadcrumb.
I think there are 2 separate problems here:
1. Where should we put all of the pages that are currently in the "Main" space if we decide that not all of them deserve to be top-level pages
Pages from the Main space are not top level. Main is top level, and Main is on the same level with Blog, Sandbox and XWiki. Check the document index tree. I have the feeling you're making a confusion.
I am making an intentional confusion because I think that this is how end-users are going to perceive it too. I think I understand well enough XWiki's current model, the reason why there's a Main space to begin with and the fact that it's just a space among others, not a top-level space by itself.
However, we cannot expect that level of implicit knowledge from a fresh new user. As a new user, I'm on "Main", which to me is the top level page, I create a new page, and it's created next to Main, not under it. That doesn't fit with my mental model of how nested pages should work. That new page should be under Main, not at the same level. Do you see what I mean?
As pointed out by Caty, I also understand that there are technical limitations that explain this behavior and that it's tough to overcome them in the short amount of time that we have as part of the 7.2 release timeframe. We'll most likely have to keep the current behavior and live with it for a while. But I know for sure that it is going to create confusion for some end users, the same way it did for me :-)
Thanks,
Guillaume
2. Making it possible to have top-level pages in a coherent manner
For 1., pages in the Main space could stay where they are for now.
"Main"
would be the legacy space where we put useful tools for the management of your wiki.
I'm discussing the answer for 2. below.
Also I wouldn't like that all the URL contain the word 'Main' Imagine that
besides the 'xwiki/bin/view/' we would need to also contain the homepage space?
My very point is that the home page wouldn't (shouldn't?) need to be "Main". It would be "". IE, there would be nothing in the URL to reflect it. It would be a representation of the wiki itself.
I understand that technically this is not feasible right now and that we *need* to have a specific page be the home page, which is the role played by Main.WebHome. What I'm saying is that with the new system, I'd rather have *.../xwiki/bin/view/WebHome => **.../xwiki/bin/view/ *would be the whole wiki. That level would be the top level space (which is exactly what has been implemented by the way). Do you see what I mean?
Although we have a convention that a certain page is displayed as homepage, this is not needed to be in the URL. 'home' icon is a link for the homepage, not a physical location. Currently the 'Main' space can contain pages useful for the display of the homepage, but is an 'optional' space.
What I' suggesting is precisely that the home page be its own document at the very top of the hierarchy, ABOVE what is currently known as Main.WebHome. This is why while the user is on this page, she should see only the home icon.
Is this making what I mean clearer? I'm just suggesting we push things one step further in the direction that has already been established.
Thanks,
Guillaume
Thanks,
Caty
On Mon, Sep 14, 2015 at 11:25 AM, Guillaume Lerouge < [email protected]> wrote:
> Hi Edy, > > thanks for the explanation. Please see my feedback below. > > On Fri, Sep 11, 2015 at 5:24 PM, Eduard Moraru < [email protected]> > wrote: > > > Hi, > > > > Yes, "this is not a bug, it's a feature!" :) I had documented it in a > small > > paragraph [1] (see the note) but did not feel it was worthy to be > mentioned > > in the release notes. Please feel free to rephrase if needed. > > > > It's not specifically about "Main", but about the current wiki's homepage > > (and "Main.WebHome" is the default homepage that can be changed from > > administration). > > > > Does this feature (changing the home page) still makes sense in the context > of nested spaces? What is the point to define the home page as ".../A/B/C" > when based on the new system, "C" is a sub-sub page? > > To me, with nested spaces the home page is always the same and cannot be > changed. You may want to add a redirect, but this doesn't change the fact > that the top page is the same. > > > > The effort is to try to avoid the situation where a regular user lands on > > the homepage of the wiki (just accessed the wiki or maybe he clicked the > > logo) and wants to create a document. He enters the title and presses > > "create". Obviously his intention was to create a page, and, more often > > than not (IMO at least), his actual intention was to create a top level > > document and not a child document of the wiki's current homepage. > > > > I agree with this. However, in that case, shouldn't the home page be simply > *https://<server>/xwiki/bin/view/* instead of > *https://<server>/xwiki/bin/view/Main/* ? > > Using short URLs, you could even have the home page under *https:// > <server>/ > *and then subpages at *https://<server>/A, **https:// <server>/A/B* and so > on. This would be in line with what most CMS do and it would fix your > issue: any page created from the home is a sub-page at the expected level. > > Image the homepage gets changed to "Some.Deep.Document.As.Homepage". > > Without this "trick", a regular user would end up, by mistake IMO (and by > > using the "next-next-next" mindset), creating the document > > "Some.Deep.Document.As.Homepage.NewDocument". > > > > As I said above, I actually think we should remove this feature in the > context of nested spaces. > > > > Even if the homepage remains the default one, I see no logical reason in > > spamming all the new documents with the "Main" prefix, the result being > an > > artificially deeper hierarchy and longer URL. > > > > Agreed. As mentioned above, ideally we'd remove it. > > > > If a user really intended to create a document as a child of the homepage > > (rare usecase IMO), he has all the tools in the UI to simply do so. > > > > I agree that it's a minor consistency dent, but IMO the benefit justifies > > it. > > > > I don't quite agree that it's minor. One of the implied goals of nested > spaces is to be able to have consistent URL naming (I know exactly where > page *https://<server>/A/B/C *is). Having a special case for Main breaks > this. > > Similarly, when on the home page on the main wiki, I don't understand why > the breadcrumb shows both the "home" icon and "Home" text. Why keep both > when the icon would be enough? > > Thanks, > > Guillaume > > WDYT? (interested in more opinions on this since I've already had 2 > > eyebrows raised on this topic :) ) > > > > Thanks, > > Eduard > > > > --------- > > [1] > > > > >
http://platform.xwiki.org/xwiki/bin/view/Features/DocumentLifecycle#HByusing...
> > > > On Fri, Sep 11, 2015 at 4:42 PM, Guillaume Lerouge < [email protected]> > > wrote: > > > > > Hi Devs, > > > > > > I started trying out XE 7.2 (SNAPSHOT from around 12:30 today) and I > was > > > very impressed, the changes look quite good! > > > > > > While playing with it, I had a question about how the "Main" space is > > > handled. Here's what I did: from .../xwiki/bin/view/Main/, I clicked > the > > > "create" button and created a sub page, then a sub-sub page. Here's > what > > I > > > got: > > > > > > - .../xwiki/bin/view/SubPage/SubSubPage > > > > > > Although I was expecting this: > > > > > > - .../xwiki/bin/view/Main/SubPage/SubSubPage > > > > > > So I was wondering whether this was the expected behavior, and whether > it > > > had been discussed before? > > > > > > Congrats & Thanks, > > > > > > Guillaume
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (4)
-
Ecaterina Moraru (Valica) -
Eduard Moraru -
Guillaume Lerouge -
Marius Dumitru Florea