[Idea] Deprecate terminal pages

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

[Idea] Deprecate terminal pages

Guillaume Lerouge
Hi Devs,

after trying XE 7.4 snapshot some more, I kept asking myself what was the
point of even allowing terminal pages to exists. I couldn't see a good
reason why any given page would *need* to be terminal, whereas it poses
some issues:

   - There is no visual distinction between terminal pages and nested pages
   in the interface (besides "WebHome" in the URL, which would be cleaner to
   remove)
   - We're planning to make it possible to reference a nested page in wiki
   syntax without having to write "WebHome" in it
   - When creating a new page from a terminal page, you're creating a
   sibling instead of a child page, which breaks the user expectation (and the
   breadcrumb)
   - For AWM applications, data/content pages are created as terminal
   pages, which makes it impossible to add further content underneath them in
   the future (say, sub-tasks that would go as child pages of tasks)
   - To my knowledge, there is no easy way to transform a terminal page
   into a nested page should the need arise later on
   - However, I don't see any problem from a page being a nested page
   instead of being a terminal page

In summary: why bother with terminal pages at all? I understand they're an
artefact from our pre-nested-spaces model, but do they really make sense
now? We could let existing terminal pages live on, but not remove the
ability to create new ones even for admins.

Am I missing something obvious?

Thanks,

Guillaume
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Idea] Deprecate terminal pages

Marius Dumitru Florea
On Thu, Nov 26, 2015 at 4:55 PM, Guillaume Lerouge <[hidden email]>
wrote:

> Hi Devs,
>
> after trying XE 7.4 snapshot some more, I kept asking myself what was the
> point of even allowing terminal pages to exists. I couldn't see a good
> reason why any given page would *need* to be terminal, whereas it poses
> some issues:
>
>    - There is no visual distinction between terminal pages and nested pages
>    in the interface (besides "WebHome" in the URL, which would be cleaner
> to
>    remove)
>    - We're planning to make it possible to reference a nested page in wiki
>    syntax without having to write "WebHome" in it
>    - When creating a new page from a terminal page, you're creating a
>    sibling instead of a child page, which breaks the user expectation (and
> the
>    breadcrumb)
>


>    - For AWM applications, data/content pages are created as terminal
>    pages, which makes it impossible to add further content underneath them
> in
>    the future (say, sub-tasks that would go as child pages of tasks)
>    - To my knowledge, there is no easy way to transform a terminal page
>    into a nested page should the need arise later on
>

See http://lists.xwiki.org/pipermail/users/2015-November/031558.html


>    - However, I don't see any problem from a page being a nested page
>    instead of being a terminal page
>
> In summary: why bother with terminal pages at all? I understand they're an
> artefact from our pre-nested-spaces model, but do they really make sense
> now? We could let existing terminal pages live on, but not remove the
> ability to create new ones even for admins.
>
> Am I missing something obvious?
>
> Thanks,
>
> Guillaume
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Idea] Deprecate terminal pages

Guillaume Lerouge
Hi Marius,

On Fri, Nov 27, 2015 at 12:40 PM, Marius Dumitru Florea <
[hidden email]> wrote:

> On Thu, Nov 26, 2015 at 4:55 PM, Guillaume Lerouge <[hidden email]>
> wrote:
>
> > Hi Devs,
> >
> > after trying XE 7.4 snapshot some more, I kept asking myself what was the
> > point of even allowing terminal pages to exists. I couldn't see a good
> > reason why any given page would *need* to be terminal, whereas it poses
> > some issues:
> >
> >    - There is no visual distinction between terminal pages and nested
> pages
> >    in the interface (besides "WebHome" in the URL, which would be cleaner
> > to
> >    remove)
> >    - We're planning to make it possible to reference a nested page in
> wiki
> >    syntax without having to write "WebHome" in it
> >    - When creating a new page from a terminal page, you're creating a
> >    sibling instead of a child page, which breaks the user expectation
> (and
> > the
> >    breadcrumb)
> >
>
>
> >    - For AWM applications, data/content pages are created as terminal
> >    pages, which makes it impossible to add further content underneath
> them
> > in
> >    the future (say, sub-tasks that would go as child pages of tasks)
> >    - To my knowledge, there is no easy way to transform a terminal page
> >    into a nested page should the need arise later on
> >
>
> See http://lists.xwiki.org/pipermail/users/2015-November/031558.html


Thanks. I understand it's fine to have terminal pages, but are they really
*needed*?

My feeling is that keeping this concept generates complexity for no obvious
benefit.

Guillaume


> >    - However, I don't see any problem from a page being a nested page
> >    instead of being a terminal page
> >
> > In summary: why bother with terminal pages at all? I understand they're
> an
> > artefact from our pre-nested-spaces model, but do they really make sense
> > now? We could let existing terminal pages live on, but not remove the
> > ability to create new ones even for admins.
> >
> > Am I missing something obvious?
> >
> > Thanks,
> >
> > Guillaume
> > _______________________________________________
> > devs mailing list
> > [hidden email]
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Idea] Deprecate terminal pages

vmassol
Administrator


On 27 Nov 2015 at 14:25:17, Guillaume Lerouge ([hidden email](mailto:[hidden email])) wrote:

> Hi Marius,
>  
> On Fri, Nov 27, 2015 at 12:40 PM, Marius Dumitru Florea <
> [hidden email]> wrote:
>  
> > On Thu, Nov 26, 2015 at 4:55 PM, Guillaume Lerouge  
> > wrote:
> >
> > > Hi Devs,
> > >
> > > after trying XE 7.4 snapshot some more, I kept asking myself what was the
> > > point of even allowing terminal pages to exists. I couldn't see a good
> > > reason why any given page would *need* to be terminal, whereas it poses
> > > some issues:
> > >
> > > - There is no visual distinction between terminal pages and nested
> > pages
> > > in the interface (besides "WebHome" in the URL, which would be cleaner
> > > to
> > > remove)
> > > - We're planning to make it possible to reference a nested page in
> > wiki
> > > syntax without having to write "WebHome" in it
> > > - When creating a new page from a terminal page, you're creating a
> > > sibling instead of a child page, which breaks the user expectation
> > (and
> > > the
> > > breadcrumb)
> > >
> >
> >
> > > - For AWM applications, data/content pages are created as terminal
> > > pages, which makes it impossible to add further content underneath
> > them
> > > in
> > > the future (say, sub-tasks that would go as child pages of tasks)
> > > - To my knowledge, there is no easy way to transform a terminal page
> > > into a nested page should the need arise later on
> > >
> >
> > See http://lists.xwiki.org/pipermail/users/2015-November/031558.html
>  
>  
> Thanks. I understand it's fine to have terminal pages, but are they really
> *needed*?
>  
> My feeling is that keeping this concept generates complexity for no obvious
> benefit.


What really generates complexity ATM is the difference between the UI (Nested Pages) and the Model (Nested Spaces). I’d like to start a design to explore what options we have to remove the concept of Spaces in the model and only have pages. I have the feeling it’s going to be tough to not break everything but need to explore it to know our options.

I feel that terminal pages are already well hidden in the UI so I’m not sure why you think we should remove it completely from the UI. Why do you fear that it’s too advanced for advanced users?

Thanks
-Vincent
 

> Guillaume
>  
>  
> > > - However, I don't see any problem from a page being a nested page
> > > instead of being a terminal page
> > >
> > > In summary: why bother with terminal pages at all? I understand they're
> > an
> > > artefact from our pre-nested-spaces model, but do they really make sense
> > > now? We could let existing terminal pages live on, but not remove the
> > > ability to create new ones even for admins.
> > >
> > > Am I missing something obvious?
> > >
> > > Thanks,
> > >
> > > Guillaume
> > > _______________________________________________
> > > devs mailing list
> > > [hidden email]
> > > http://lists.xwiki.org/mailman/listinfo/devs
> > >
> > _______________________________________________
> > devs mailing list
> > [hidden email]
> > http://lists.xwiki.org/mailman/listinfo/devs
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Idea] Deprecate terminal pages

Guillaume Lerouge
Hi,

> Hi Marius,
> >
> > On Fri, Nov 27, 2015 at 12:40 PM, Marius Dumitru Florea <
> > [hidden email]> wrote:
> >
> > > On Thu, Nov 26, 2015 at 4:55 PM, Guillaume Lerouge
> > > wrote:
> > >
> > > > Hi Devs,
> > > >
> > > > after trying XE 7.4 snapshot some more, I kept asking myself what
> was the
> > > > point of even allowing terminal pages to exists. I couldn't see a
> good
> > > > reason why any given page would *need* to be terminal, whereas it
> poses
> > > > some issues:
> > > >
> > > > - There is no visual distinction between terminal pages and nested
> > > pages
> > > > in the interface (besides "WebHome" in the URL, which would be
> cleaner
> > > > to
> > > > remove)
> > > > - We're planning to make it possible to reference a nested page in
> > > wiki
> > > > syntax without having to write "WebHome" in it
> > > > - When creating a new page from a terminal page, you're creating a
> > > > sibling instead of a child page, which breaks the user expectation
> > > (and
> > > > the
> > > > breadcrumb)
> > > >
> > >
> > >
> > > > - For AWM applications, data/content pages are created as terminal
> > > > pages, which makes it impossible to add further content underneath
> > > them
> > > > in
> > > > the future (say, sub-tasks that would go as child pages of tasks)
> > > > - To my knowledge, there is no easy way to transform a terminal page
> > > > into a nested page should the need arise later on
> > > >
> > >
> > > See http://lists.xwiki.org/pipermail/users/2015-November/031558.html
> >
> >
> > Thanks. I understand it's fine to have terminal pages, but are they
> really
> > *needed*?
> >
> > My feeling is that keeping this concept generates complexity for no
> obvious
> > benefit.
>
>
> What really generates complexity ATM is the difference between the UI
> (Nested Pages) and the Model (Nested Spaces). I’d like to start a design to
> explore what options we have to remove the concept of Spaces in the model
> and only have pages. I have the feeling it’s going to be tough to not break
> everything but need to explore it to know our options.
>
> I feel that terminal pages are already well hidden in the UI so I’m not
> sure why you think we should remove it completely from the UI. Why do you
> fear that it’s too advanced for advanced users?
>

2 reasons:

*1/ Practical reason:* as a simple user, if I go to a terminal page and
create a page from there, I will create a sibling to the current page
instead of a child to the current page. I will not know why it happened
like this, nor will I have the ability to change it.

*2/ Philosophical reason:* why keep something useless if we could as well
remove it? That would be an application of Ockham's razor principle if you
will.

Thanks,

Guillaume


> Thanks
> -Vincent
>
> > Guillaume
> >
> >
> > > > - However, I don't see any problem from a page being a nested page
> > > > instead of being a terminal page
> > > >
> > > > In summary: why bother with terminal pages at all? I understand
> they're
> > > an
> > > > artefact from our pre-nested-spaces model, but do they really make
> sense
> > > > now? We could let existing terminal pages live on, but not remove the
> > > > ability to create new ones even for admins.
> > > >
> > > > Am I missing something obvious?
> > > >
> > > > Thanks,
> > > >
> > > > Guillaume
> > > > _______________________________________________
> > > > devs mailing list
> > > > [hidden email]
> > > > http://lists.xwiki.org/mailman/listinfo/devs
> > > >
> > > _______________________________________________
> > > devs mailing list
> > > [hidden email]
> > > http://lists.xwiki.org/mailman/listinfo/devs
> > _______________________________________________
> > devs mailing list
> > [hidden email]
> > http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Idea] Deprecate terminal pages

vmassol
Administrator



On 27 Nov 2015 at 16:42:39, Guillaume Lerouge ([hidden email](mailto:[hidden email])) wrote:

> Hi,
>  
> > Hi Marius,
> > >
> > > On Fri, Nov 27, 2015 at 12:40 PM, Marius Dumitru Florea <
> > > [hidden email]> wrote:
> > >
> > > > On Thu, Nov 26, 2015 at 4:55 PM, Guillaume Lerouge
> > > > wrote:
> > > >
> > > > > Hi Devs,
> > > > >
> > > > > after trying XE 7.4 snapshot some more, I kept asking myself what
> > was the
> > > > > point of even allowing terminal pages to exists. I couldn't see a
> > good
> > > > > reason why any given page would *need* to be terminal, whereas it
> > poses
> > > > > some issues:
> > > > >
> > > > > - There is no visual distinction between terminal pages and nested
> > > > pages
> > > > > in the interface (besides "WebHome" in the URL, which would be
> > cleaner
> > > > > to
> > > > > remove)
> > > > > - We're planning to make it possible to reference a nested page in
> > > > wiki
> > > > > syntax without having to write "WebHome" in it
> > > > > - When creating a new page from a terminal page, you're creating a
> > > > > sibling instead of a child page, which breaks the user expectation
> > > > (and
> > > > > the
> > > > > breadcrumb)
> > > > >
> > > >
> > > >
> > > > > - For AWM applications, data/content pages are created as terminal
> > > > > pages, which makes it impossible to add further content underneath
> > > > them
> > > > > in
> > > > > the future (say, sub-tasks that would go as child pages of tasks)
> > > > > - To my knowledge, there is no easy way to transform a terminal page
> > > > > into a nested page should the need arise later on
> > > > >
> > > >
> > > > See http://lists.xwiki.org/pipermail/users/2015-November/031558.html
> > >
> > >
> > > Thanks. I understand it's fine to have terminal pages, but are they
> > really
> > > *needed*?
> > >
> > > My feeling is that keeping this concept generates complexity for no
> > obvious
> > > benefit.
> >
> >
> > What really generates complexity ATM is the difference between the UI
> > (Nested Pages) and the Model (Nested Spaces). I’d like to start a design to
> > explore what options we have to remove the concept of Spaces in the model
> > and only have pages. I have the feeling it’s going to be tough to not break
> > everything but need to explore it to know our options.
> >
> > I feel that terminal pages are already well hidden in the UI so I’m not
> > sure why you think we should remove it completely from the UI. Why do you
> > fear that it’s too advanced for advanced users?
> >
>  
> 2 reasons:
>  
> *1/ Practical reason:* as a simple user, if I go to a terminal page and
> create a page from there, I will create a sibling to the current page
> instead of a child to the current page. I will not know why it happened
> like this, nor will I have the ability to change it.

Right now users can already create sibling pages when they click the Add button on a page.

It would be easy to add a small warning when you’re on a terminal page and you click Add to mention that this is a terminal page that cannot have children.

> *2/ Philosophical reason:* why keep something useless if we could as well
> remove it? That would be an application of Ockham's razor principle if you
> will.

It’s not useless. As I mentioned this is still in the model and we still support it. This means that we need a way for advanced users to be able to create those pages (and using a script to do so is worse than having a nice UI for it).

Thanks
-Vincent

> Thanks,
>  
> Guillaume
>  
>  
> > Thanks
> > -Vincent
> >
> > > Guillaume
> > >
> > >
> > > > > - However, I don't see any problem from a page being a nested page
> > > > > instead of being a terminal page
> > > > >
> > > > > In summary: why bother with terminal pages at all? I understand
> > they're
> > > > an
> > > > > artefact from our pre-nested-spaces model, but do they really make
> > sense
> > > > > now? We could let existing terminal pages live on, but not remove the
> > > > > ability to create new ones even for admins.
> > > > >
> > > > > Am I missing something obvious?
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Guillaume
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Idea] Deprecate terminal pages

Guillaume Lerouge
Hi Vincent,

On Fri, Nov 27, 2015 at 4:53 PM, [hidden email] <[hidden email]>
wrote:

>
>
>
> On 27 Nov 2015 at 16:42:39, Guillaume Lerouge ([hidden email](mailto:
> [hidden email])) wrote:
>
> > Hi,
> >
> > > Hi Marius,
> > > >
> > > > On Fri, Nov 27, 2015 at 12:40 PM, Marius Dumitru Florea <
> > > > [hidden email]> wrote:
> > > >
> > > > > On Thu, Nov 26, 2015 at 4:55 PM, Guillaume Lerouge
> > > > > wrote:
> > > > >
> > > > > > Hi Devs,
> > > > > >
> > > > > > after trying XE 7.4 snapshot some more, I kept asking myself what
> > > was the
> > > > > > point of even allowing terminal pages to exists. I couldn't see a
> > > good
> > > > > > reason why any given page would *need* to be terminal, whereas it
> > > poses
> > > > > > some issues:
> > > > > >
> > > > > > - There is no visual distinction between terminal pages and
> nested
> > > > > pages
> > > > > > in the interface (besides "WebHome" in the URL, which would be
> > > cleaner
> > > > > > to
> > > > > > remove)
> > > > > > - We're planning to make it possible to reference a nested page
> in
> > > > > wiki
> > > > > > syntax without having to write "WebHome" in it
> > > > > > - When creating a new page from a terminal page, you're creating
> a
> > > > > > sibling instead of a child page, which breaks the user
> expectation
> > > > > (and
> > > > > > the
> > > > > > breadcrumb)
> > > > > >
> > > > >
> > > > >
> > > > > > - For AWM applications, data/content pages are created as
> terminal
> > > > > > pages, which makes it impossible to add further content
> underneath
> > > > > them
> > > > > > in
> > > > > > the future (say, sub-tasks that would go as child pages of tasks)
> > > > > > - To my knowledge, there is no easy way to transform a terminal
> page
> > > > > > into a nested page should the need arise later on
> > > > > >
> > > > >
> > > > > See
> http://lists.xwiki.org/pipermail/users/2015-November/031558.html
> > > >
> > > >
> > > > Thanks. I understand it's fine to have terminal pages, but are they
> > > really
> > > > *needed*?
> > > >
> > > > My feeling is that keeping this concept generates complexity for no
> > > obvious
> > > > benefit.
> > >
> > >
> > > What really generates complexity ATM is the difference between the UI
> > > (Nested Pages) and the Model (Nested Spaces). I’d like to start a
> design to
> > > explore what options we have to remove the concept of Spaces in the
> model
> > > and only have pages. I have the feeling it’s going to be tough to not
> break
> > > everything but need to explore it to know our options.
> > >
> > > I feel that terminal pages are already well hidden in the UI so I’m not
> > > sure why you think we should remove it completely from the UI. Why do
> you
> > > fear that it’s too advanced for advanced users?
> > >
> >
> > 2 reasons:
> >
> > *1/ Practical reason:* as a simple user, if I go to a terminal page and
> > create a page from there, I will create a sibling to the current page
> > instead of a child to the current page. I will not know why it happened
> > like this, nor will I have the ability to change it.
>
> Right now users can already create sibling pages when they click the Add
> button on a page.
>
> It would be easy to add a small warning when you’re on a terminal page and
> you click Add to mention that this is a terminal page that cannot have
> children.
>

Right, a warning to simple users that something different than what they
expect is going to happen for a reason that they cannot fathom to begin
with since they don't even know about terminal pages in the first place.
It's a bit like telling them:

*- XWiki: You can't create a child page from here!*
*- User: But, why?*
*- XWiki: Because!*
*- User: uh...*

It only compounds the problem.

> *2/ Philosophical reason:* why keep something useless if we could as well
> > remove it? That would be an application of Ockham's razor principle if
> you
> > will.
>
> It’s not useless. As I mentioned this is still in the model and we still
> support it. This means that we need a way for advanced users to be able to
> create those pages (and using a script to do so is worse than having a nice
> UI for it).
>

I have the feeling we're running in circles here. Just because terminal
pages still exist in the model doesn't tell me *why* they're still needed
for the future.

Do you have specific use cases in mind where it's *better* for an user (or
a script!) to create a terminal page rather than a nested page? Does it
lead to performance improvements of some sort? Does it prevent backwards
compatibility issues that would be caused by switching all pages to nested
pages? Any other *benefits* from having terminal pages?

Thanks,

Guillaume


> Thanks
> -Vincent
>
> > Thanks,
> >
> > Guillaume
> >
> >
> > > Thanks
> > > -Vincent
> > >
> > > > Guillaume
> > > >
> > > >
> > > > > > - However, I don't see any problem from a page being a nested
> page
> > > > > > instead of being a terminal page
> > > > > >
> > > > > > In summary: why bother with terminal pages at all? I understand
> > > they're
> > > > > an
> > > > > > artefact from our pre-nested-spaces model, but do they really
> make
> > > sense
> > > > > > now? We could let existing terminal pages live on, but not
> remove the
> > > > > > ability to create new ones even for admins.
> > > > > >
> > > > > > Am I missing something obvious?
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Guillaume
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Idea] Deprecate terminal pages

vmassol
Administrator
 




On 27 Nov 2015 at 17:06:17, Guillaume Lerouge ([hidden email](mailto:[hidden email])) wrote:

> Hi Vincent,
>  
> On Fri, Nov 27, 2015 at 4:53 PM, [hidden email]  
> wrote:
>  
> >
> >
> >
> > On 27 Nov 2015 at 16:42:39, Guillaume Lerouge ([hidden email](mailto:
> > [hidden email])) wrote:
> >
> > > Hi,
> > >
> > > > Hi Marius,
> > > > >
> > > > > On Fri, Nov 27, 2015 at 12:40 PM, Marius Dumitru Florea <
> > > > > [hidden email]> wrote:
> > > > >
> > > > > > On Thu, Nov 26, 2015 at 4:55 PM, Guillaume Lerouge
> > > > > > wrote:
> > > > > >
> > > > > > > Hi Devs,
> > > > > > >
> > > > > > > after trying XE 7.4 snapshot some more, I kept asking myself what
> > > > was the
> > > > > > > point of even allowing terminal pages to exists. I couldn't see a
> > > > good
> > > > > > > reason why any given page would *need* to be terminal, whereas it
> > > > poses
> > > > > > > some issues:
> > > > > > >
> > > > > > > - There is no visual distinction between terminal pages and
> > nested
> > > > > > pages
> > > > > > > in the interface (besides "WebHome" in the URL, which would be
> > > > cleaner
> > > > > > > to
> > > > > > > remove)
> > > > > > > - We're planning to make it possible to reference a nested page
> > in
> > > > > > wiki
> > > > > > > syntax without having to write "WebHome" in it
> > > > > > > - When creating a new page from a terminal page, you're creating
> > a
> > > > > > > sibling instead of a child page, which breaks the user
> > expectation
> > > > > > (and
> > > > > > > the
> > > > > > > breadcrumb)
> > > > > > >
> > > > > >
> > > > > >
> > > > > > > - For AWM applications, data/content pages are created as
> > terminal
> > > > > > > pages, which makes it impossible to add further content
> > underneath
> > > > > > them
> > > > > > > in
> > > > > > > the future (say, sub-tasks that would go as child pages of tasks)
> > > > > > > - To my knowledge, there is no easy way to transform a terminal
> > page
> > > > > > > into a nested page should the need arise later on
> > > > > > >
> > > > > >
> > > > > > See
> > http://lists.xwiki.org/pipermail/users/2015-November/031558.html
> > > > >
> > > > >
> > > > > Thanks. I understand it's fine to have terminal pages, but are they
> > > > really
> > > > > *needed*?
> > > > >
> > > > > My feeling is that keeping this concept generates complexity for no
> > > > obvious
> > > > > benefit.
> > > >
> > > >
> > > > What really generates complexity ATM is the difference between the UI
> > > > (Nested Pages) and the Model (Nested Spaces). I’d like to start a
> > design to
> > > > explore what options we have to remove the concept of Spaces in the
> > model
> > > > and only have pages. I have the feeling it’s going to be tough to not
> > break
> > > > everything but need to explore it to know our options.
> > > >
> > > > I feel that terminal pages are already well hidden in the UI so I’m not
> > > > sure why you think we should remove it completely from the UI. Why do
> > you
> > > > fear that it’s too advanced for advanced users?
> > > >
> > >
> > > 2 reasons:
> > >
> > > *1/ Practical reason:* as a simple user, if I go to a terminal page and
> > > create a page from there, I will create a sibling to the current page
> > > instead of a child to the current page. I will not know why it happened
> > > like this, nor will I have the ability to change it.
> >
> > Right now users can already create sibling pages when they click the Add
> > button on a page.
> >
> > It would be easy to add a small warning when you’re on a terminal page and
> > you click Add to mention that this is a terminal page that cannot have
> > children.
> >
>  
> Right, a warning to simple users that something different than what they
> expect is going to happen for a reason that they cannot fathom to begin
> with since they don't even know about terminal pages in the first place.
> It's a bit like telling them:
>  
> *- XWiki: You can't create a child page from here!*
> *- User: But, why?*
> *- XWiki: Because!*
> *- User: uh...*
>  
> It only compounds the problem.
>  
> > *2/ Philosophical reason:* why keep something useless if we could as well
> > > remove it? That would be an application of Ockham's razor principle if
> > you
> > > will.
> >
> > It’s not useless. As I mentioned this is still in the model and we still
> > support it. This means that we need a way for advanced users to be able to
> > create those pages (and using a script to do so is worse than having a nice
> > UI for it).
> >
>  
> I have the feeling we're running in circles here. Just because terminal
> pages still exist in the model doesn't tell me *why* they're still needed
> for the future.
>  
> Do you have specific use cases in mind where it's *better* for an user (or
> a script!) to create a terminal page rather than a nested page? Does it
> lead to performance improvements of some sort? Does it prevent backwards
> compatibility issues that would be caused by switching all pages to nested
> pages? Any other *benefits* from having terminal pages?

I could list use cases (like some cases where it doesn’t make sense to have nested pages - like WebPreferences for example - Actually check a filesystem, you can’t create a subfile inside a file after all, I think users understand that) but anyway it doesn’t matter. The simple fact that we have terminal pages in lots of extensions require that the user be able to create terminal pages.

Imagine that someone deletes a terminal page by error and you need to recreate it. You need a way to do that or your extension is not going to work.

Thanks
-Vincent

> Thanks,
>  
> Guillaume
>  
>  
> > Thanks
> > -Vincent
> >
> > > Thanks,
> > >
> > > Guillaume
> > >
> > >
> > > > Thanks
> > > > -Vincent
> > > >
> > > > > Guillaume
> > > > >
> > > > >
> > > > > > > - However, I don't see any problem from a page being a nested
> > page
> > > > > > > instead of being a terminal page
> > > > > > >
> > > > > > > In summary: why bother with terminal pages at all? I understand
> > > > they're
> > > > > > an
> > > > > > > artefact from our pre-nested-spaces model, but do they really
> > make
> > > > sense
> > > > > > > now? We could let existing terminal pages live on, but not
> > remove the
> > > > > > > ability to create new ones even for admins.
> > > > > > >
> > > > > > > Am I missing something obvious?
> > > > > > >
> > > > > > > Thanks,
> > > > > > >
> > > > > > > Guillaume
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Idea] Deprecate terminal pages

Caleb James DeLisle-3
I can't imagine how I would attempt to explain a terminal (but not meaning it's going to die soon)
page to someone who doesn't know the insides of the sausage factory.

Every page is like a file, and it's also like a folder because it can have pages inside of it,
except for the ones that can't...

So +1 that users should never see/create/edit these weird pages which cannot have children.

Thanks,
Caleb


On 27/11/15 17:10, [hidden email] wrote:

>
>
>
>
>
> On 27 Nov 2015 at 17:06:17, Guillaume Lerouge ([hidden email](mailto:[hidden email])) wrote:
>
>> Hi Vincent,
>>
>> On Fri, Nov 27, 2015 at 4:53 PM, [hidden email]
>> wrote:
>>
>>>
>>>
>>>
>>> On 27 Nov 2015 at 16:42:39, Guillaume Lerouge ([hidden email](mailto:
>>> [hidden email])) wrote:
>>>
>>>> Hi,
>>>>
>>>>> Hi Marius,
>>>>>>
>>>>>> On Fri, Nov 27, 2015 at 12:40 PM, Marius Dumitru Florea <
>>>>>> [hidden email]> wrote:
>>>>>>
>>>>>>> On Thu, Nov 26, 2015 at 4:55 PM, Guillaume Lerouge
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Devs,
>>>>>>>>
>>>>>>>> after trying XE 7.4 snapshot some more, I kept asking myself what
>>>>> was the
>>>>>>>> point of even allowing terminal pages to exists. I couldn't see a
>>>>> good
>>>>>>>> reason why any given page would *need* to be terminal, whereas it
>>>>> poses
>>>>>>>> some issues:
>>>>>>>>
>>>>>>>> - There is no visual distinction between terminal pages and
>>> nested
>>>>>>> pages
>>>>>>>> in the interface (besides "WebHome" in the URL, which would be
>>>>> cleaner
>>>>>>>> to
>>>>>>>> remove)
>>>>>>>> - We're planning to make it possible to reference a nested page
>>> in
>>>>>>> wiki
>>>>>>>> syntax without having to write "WebHome" in it
>>>>>>>> - When creating a new page from a terminal page, you're creating
>>> a
>>>>>>>> sibling instead of a child page, which breaks the user
>>> expectation
>>>>>>> (and
>>>>>>>> the
>>>>>>>> breadcrumb)
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> - For AWM applications, data/content pages are created as
>>> terminal
>>>>>>>> pages, which makes it impossible to add further content
>>> underneath
>>>>>>> them
>>>>>>>> in
>>>>>>>> the future (say, sub-tasks that would go as child pages of tasks)
>>>>>>>> - To my knowledge, there is no easy way to transform a terminal
>>> page
>>>>>>>> into a nested page should the need arise later on
>>>>>>>>
>>>>>>>
>>>>>>> See
>>> http://lists.xwiki.org/pipermail/users/2015-November/031558.html
>>>>>>
>>>>>>
>>>>>> Thanks. I understand it's fine to have terminal pages, but are they
>>>>> really
>>>>>> *needed*?
>>>>>>
>>>>>> My feeling is that keeping this concept generates complexity for no
>>>>> obvious
>>>>>> benefit.
>>>>>
>>>>>
>>>>> What really generates complexity ATM is the difference between the UI
>>>>> (Nested Pages) and the Model (Nested Spaces). I’d like to start a
>>> design to
>>>>> explore what options we have to remove the concept of Spaces in the
>>> model
>>>>> and only have pages. I have the feeling it’s going to be tough to not
>>> break
>>>>> everything but need to explore it to know our options.
>>>>>
>>>>> I feel that terminal pages are already well hidden in the UI so I’m not
>>>>> sure why you think we should remove it completely from the UI. Why do
>>> you
>>>>> fear that it’s too advanced for advanced users?
>>>>>
>>>>
>>>> 2 reasons:
>>>>
>>>> *1/ Practical reason:* as a simple user, if I go to a terminal page and
>>>> create a page from there, I will create a sibling to the current page
>>>> instead of a child to the current page. I will not know why it happened
>>>> like this, nor will I have the ability to change it.
>>>
>>> Right now users can already create sibling pages when they click the Add
>>> button on a page.
>>>
>>> It would be easy to add a small warning when you’re on a terminal page and
>>> you click Add to mention that this is a terminal page that cannot have
>>> children.
>>>
>>
>> Right, a warning to simple users that something different than what they
>> expect is going to happen for a reason that they cannot fathom to begin
>> with since they don't even know about terminal pages in the first place.
>> It's a bit like telling them:
>>
>> *- XWiki: You can't create a child page from here!*
>> *- User: But, why?*
>> *- XWiki: Because!*
>> *- User: uh...*
>>
>> It only compounds the problem.
>>
>>> *2/ Philosophical reason:* why keep something useless if we could as well
>>>> remove it? That would be an application of Ockham's razor principle if
>>> you
>>>> will.
>>>
>>> It’s not useless. As I mentioned this is still in the model and we still
>>> support it. This means that we need a way for advanced users to be able to
>>> create those pages (and using a script to do so is worse than having a nice
>>> UI for it).
>>>
>>
>> I have the feeling we're running in circles here. Just because terminal
>> pages still exist in the model doesn't tell me *why* they're still needed
>> for the future.
>>
>> Do you have specific use cases in mind where it's *better* for an user (or
>> a script!) to create a terminal page rather than a nested page? Does it
>> lead to performance improvements of some sort? Does it prevent backwards
>> compatibility issues that would be caused by switching all pages to nested
>> pages? Any other *benefits* from having terminal pages?
>
> I could list use cases (like some cases where it doesn’t make sense to have nested pages - like WebPreferences for example - Actually check a filesystem, you can’t create a subfile inside a file after all, I think users understand that) but anyway it doesn’t matter. The simple fact that we have terminal pages in lots of extensions require that the user be able to create terminal pages.
>
> Imagine that someone deletes a terminal page by error and you need to recreate it. You need a way to do that or your extension is not going to work.
>
> Thanks
> -Vincent
>
>> Thanks,
>>
>> Guillaume
>>
>>
>>> Thanks
>>> -Vincent
>>>
>>>> Thanks,
>>>>
>>>> Guillaume
>>>>
>>>>
>>>>> Thanks
>>>>> -Vincent
>>>>>
>>>>>> Guillaume
>>>>>>
>>>>>>
>>>>>>>> - However, I don't see any problem from a page being a nested
>>> page
>>>>>>>> instead of being a terminal page
>>>>>>>>
>>>>>>>> In summary: why bother with terminal pages at all? I understand
>>>>> they're
>>>>>>> an
>>>>>>>> artefact from our pre-nested-spaces model, but do they really
>>> make
>>>>> sense
>>>>>>>> now? We could let existing terminal pages live on, but not
>>> remove the
>>>>>>>> ability to create new ones even for admins.
>>>>>>>>
>>>>>>>> Am I missing something obvious?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Guillaume
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Idea] Deprecate terminal pages

Guillaume Lerouge
Hi Devs,

another observation regarding this. Earlier today I watched a new user who
was trying XWiki 7.3. He had created a number of pages as terminal pages.
Then he tried to move some pages from their existing location to another
location, using the tree.

Unfortunately, several times, when trying to drop the page under an
existing page, a "cancel" icon was displayed when he tried to click on the
"Select" button. Of course the reason was that he was trying to drop his
page under a terminal page, but there was no explanation about this in the
UI. It also took me a while to figure things out :-)

All in all that was a very frustrating experience to watch. To me, that's
another reason why I think we should really look at how we could deprecate
terminal pages. I see them being the source of many misunderstandings and
additional issues like this one.

Thanks,

Guillaume

On Fri, Nov 27, 2015 at 5:27 PM, Caleb James DeLisle <[hidden email]> wrote:

> I can't imagine how I would attempt to explain a terminal (but not meaning
> it's going to die soon)
> page to someone who doesn't know the insides of the sausage factory.
>
> Every page is like a file, and it's also like a folder because it can have
> pages inside of it,
> except for the ones that can't...
>
> So +1 that users should never see/create/edit these weird pages which
> cannot have children.
>
> Thanks,
> Caleb
>
>
>
> On 27/11/15 17:10, [hidden email] wrote:
>
>>
>>
>>
>>
>>
>> On 27 Nov 2015 at 17:06:17, Guillaume Lerouge ([hidden email]
>> (mailto:[hidden email])) wrote:
>>
>> Hi Vincent,
>>>
>>> On Fri, Nov 27, 2015 at 4:53 PM, [hidden email]
>>> wrote:
>>>
>>>
>>>>
>>>>
>>>> On 27 Nov 2015 at 16:42:39, Guillaume Lerouge ([hidden email]
>>>> (mailto:
>>>> [hidden email])) wrote:
>>>>
>>>> Hi,
>>>>>
>>>>> Hi Marius,
>>>>>>
>>>>>>>
>>>>>>> On Fri, Nov 27, 2015 at 12:40 PM, Marius Dumitru Florea <
>>>>>>> [hidden email]> wrote:
>>>>>>>
>>>>>>> On Thu, Nov 26, 2015 at 4:55 PM, Guillaume Lerouge
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi Devs,
>>>>>>>>>
>>>>>>>>> after trying XE 7.4 snapshot some more, I kept asking myself what
>>>>>>>>>
>>>>>>>> was the
>>>>>>
>>>>>>> point of even allowing terminal pages to exists. I couldn't see a
>>>>>>>>>
>>>>>>>> good
>>>>>>
>>>>>>> reason why any given page would *need* to be terminal, whereas it
>>>>>>>>>
>>>>>>>> poses
>>>>>>
>>>>>>> some issues:
>>>>>>>>>
>>>>>>>>> - There is no visual distinction between terminal pages and
>>>>>>>>>
>>>>>>>> nested
>>>>
>>>>> pages
>>>>>>>>
>>>>>>>>> in the interface (besides "WebHome" in the URL, which would be
>>>>>>>>>
>>>>>>>> cleaner
>>>>>>
>>>>>>> to
>>>>>>>>> remove)
>>>>>>>>> - We're planning to make it possible to reference a nested page
>>>>>>>>>
>>>>>>>> in
>>>>
>>>>> wiki
>>>>>>>>
>>>>>>>>> syntax without having to write "WebHome" in it
>>>>>>>>> - When creating a new page from a terminal page, you're creating
>>>>>>>>>
>>>>>>>> a
>>>>
>>>>> sibling instead of a child page, which breaks the user
>>>>>>>>>
>>>>>>>> expectation
>>>>
>>>>> (and
>>>>>>>>
>>>>>>>>> the
>>>>>>>>> breadcrumb)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> - For AWM applications, data/content pages are created as
>>>>>>>>>
>>>>>>>> terminal
>>>>
>>>>> pages, which makes it impossible to add further content
>>>>>>>>>
>>>>>>>> underneath
>>>>
>>>>> them
>>>>>>>>
>>>>>>>>> in
>>>>>>>>> the future (say, sub-tasks that would go as child pages of tasks)
>>>>>>>>> - To my knowledge, there is no easy way to transform a terminal
>>>>>>>>>
>>>>>>>> page
>>>>
>>>>> into a nested page should the need arise later on
>>>>>>>>>
>>>>>>>>>
>>>>>>>> See
>>>>>>>>
>>>>>>> http://lists.xwiki.org/pipermail/users/2015-November/031558.html
>>>>
>>>>>
>>>>>>>
>>>>>>> Thanks. I understand it's fine to have terminal pages, but are they
>>>>>>>
>>>>>> really
>>>>>>
>>>>>>> *needed*?
>>>>>>>
>>>>>>> My feeling is that keeping this concept generates complexity for no
>>>>>>>
>>>>>> obvious
>>>>>>
>>>>>>> benefit.
>>>>>>>
>>>>>>
>>>>>>
>>>>>> What really generates complexity ATM is the difference between the UI
>>>>>> (Nested Pages) and the Model (Nested Spaces). I’d like to start a
>>>>>>
>>>>> design to
>>>>
>>>>> explore what options we have to remove the concept of Spaces in the
>>>>>>
>>>>> model
>>>>
>>>>> and only have pages. I have the feeling it’s going to be tough to not
>>>>>>
>>>>> break
>>>>
>>>>> everything but need to explore it to know our options.
>>>>>>
>>>>>> I feel that terminal pages are already well hidden in the UI so I’m
>>>>>> not
>>>>>> sure why you think we should remove it completely from the UI. Why do
>>>>>>
>>>>> you
>>>>
>>>>> fear that it’s too advanced for advanced users?
>>>>>>
>>>>>>
>>>>> 2 reasons:
>>>>>
>>>>> *1/ Practical reason:* as a simple user, if I go to a terminal page and
>>>>> create a page from there, I will create a sibling to the current page
>>>>> instead of a child to the current page. I will not know why it happened
>>>>> like this, nor will I have the ability to change it.
>>>>>
>>>>
>>>> Right now users can already create sibling pages when they click the Add
>>>> button on a page.
>>>>
>>>> It would be easy to add a small warning when you’re on a terminal page
>>>> and
>>>> you click Add to mention that this is a terminal page that cannot have
>>>> children.
>>>>
>>>>
>>> Right, a warning to simple users that something different than what they
>>> expect is going to happen for a reason that they cannot fathom to begin
>>> with since they don't even know about terminal pages in the first place.
>>> It's a bit like telling them:
>>>
>>> *- XWiki: You can't create a child page from here!*
>>> *- User: But, why?*
>>> *- XWiki: Because!*
>>> *- User: uh...*
>>>
>>> It only compounds the problem.
>>>
>>> *2/ Philosophical reason:* why keep something useless if we could as well
>>>>
>>>>> remove it? That would be an application of Ockham's razor principle if
>>>>>
>>>> you
>>>>
>>>>> will.
>>>>>
>>>>
>>>> It’s not useless. As I mentioned this is still in the model and we still
>>>> support it. This means that we need a way for advanced users to be able
>>>> to
>>>> create those pages (and using a script to do so is worse than having a
>>>> nice
>>>> UI for it).
>>>>
>>>>
>>> I have the feeling we're running in circles here. Just because terminal
>>> pages still exist in the model doesn't tell me *why* they're still needed
>>> for the future.
>>>
>>> Do you have specific use cases in mind where it's *better* for an user
>>> (or
>>> a script!) to create a terminal page rather than a nested page? Does it
>>> lead to performance improvements of some sort? Does it prevent backwards
>>> compatibility issues that would be caused by switching all pages to
>>> nested
>>> pages? Any other *benefits* from having terminal pages?
>>>
>>
>> I could list use cases (like some cases where it doesn’t make sense to
>> have nested pages - like WebPreferences for example - Actually check a
>> filesystem, you can’t create a subfile inside a file after all, I think
>> users understand that) but anyway it doesn’t matter. The simple fact that
>> we have terminal pages in lots of extensions require that the user be able
>> to create terminal pages.
>>
>> Imagine that someone deletes a terminal page by error and you need to
>> recreate it. You need a way to do that or your extension is not going to
>> work.
>>
>> Thanks
>> -Vincent
>>
>> Thanks,
>>>
>>> Guillaume
>>>
>>>
>>> Thanks
>>>> -Vincent
>>>>
>>>> Thanks,
>>>>>
>>>>> Guillaume
>>>>>
>>>>>
>>>>> Thanks
>>>>>> -Vincent
>>>>>>
>>>>>> Guillaume
>>>>>>>
>>>>>>>
>>>>>>> - However, I don't see any problem from a page being a nested
>>>>>>>>>
>>>>>>>> page
>>>>
>>>>> instead of being a terminal page
>>>>>>>>>
>>>>>>>>> In summary: why bother with terminal pages at all? I understand
>>>>>>>>>
>>>>>>>> they're
>>>>>>
>>>>>>> an
>>>>>>>>
>>>>>>>>> artefact from our pre-nested-spaces model, but do they really
>>>>>>>>>
>>>>>>>> make
>>>>
>>>>> sense
>>>>>>
>>>>>>> now? We could let existing terminal pages live on, but not
>>>>>>>>>
>>>>>>>> remove the
>>>>
>>>>> ability to create new ones even for admins.
>>>>>>>>>
>>>>>>>>> Am I missing something obvious?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Guillaume
>>>>>>>>>
>>>>>>>> _______________________________________________
>> devs mailing list
>> [hidden email]
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
>> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Idea] Deprecate terminal pages

Marius Dumitru Florea
On Tue, Dec 15, 2015 at 10:23 PM, Guillaume Lerouge <[hidden email]>
wrote:

> Hi Devs,
>
> another observation regarding this. Earlier today I watched a new user who
> was trying XWiki 7.3. He had created a number of pages as terminal pages.
>

Did he use the default Admin profile (which is configured as advanced) or
did he register a new profile (which is not advanced unless you configure
it explicitly)? The default Admin profile is not the best way to test XWiki
if you are a simple user.


> Then he tried to move some pages from their existing location to another
> location, using the tree.
>

You mean using the Rename Page action, selecting the new location using the
tree? As in
http://platform.xwiki.org/xwiki/bin/view/Features/DocumentLifecycle#HMove2FRename
.


>
> Unfortunately, several times, when trying to drop the page under an
> existing page, a "cancel" icon was displayed when he tried to click on the
> "Select" button. Of course the reason was that he was trying to drop his
> page under a terminal page, but there was no explanation about this in the
> UI. It also took me a while to figure things out :-)
>

The tree from the Rename Page UI doesn't show terminal pages and doesn't
support drag&drop. The "Select" button from the "Select Page" modal popup
that displays the tree is disabled when there is no page selected in the
tree. So I don't understand what you are talking about.

Thanks,
Marius


>
> All in all that was a very frustrating experience to watch. To me, that's
> another reason why I think we should really look at how we could deprecate
> terminal pages. I see them being the source of many misunderstandings and
> additional issues like this one.
>
> Thanks,
>
> Guillaume
>
> On Fri, Nov 27, 2015 at 5:27 PM, Caleb James DeLisle <[hidden email]> wrote:
>
> > I can't imagine how I would attempt to explain a terminal (but not
> meaning
> > it's going to die soon)
> > page to someone who doesn't know the insides of the sausage factory.
> >
> > Every page is like a file, and it's also like a folder because it can
> have
> > pages inside of it,
> > except for the ones that can't...
> >
> > So +1 that users should never see/create/edit these weird pages which
> > cannot have children.
> >
> > Thanks,
> > Caleb
> >
> >
> >
> > On 27/11/15 17:10, [hidden email] wrote:
> >
> >>
> >>
> >>
> >>
> >>
> >> On 27 Nov 2015 at 17:06:17, Guillaume Lerouge ([hidden email]
> >> (mailto:[hidden email])) wrote:
> >>
> >> Hi Vincent,
> >>>
> >>> On Fri, Nov 27, 2015 at 4:53 PM, [hidden email]
> >>> wrote:
> >>>
> >>>
> >>>>
> >>>>
> >>>> On 27 Nov 2015 at 16:42:39, Guillaume Lerouge ([hidden email]
> >>>> (mailto:
> >>>> [hidden email])) wrote:
> >>>>
> >>>> Hi,
> >>>>>
> >>>>> Hi Marius,
> >>>>>>
> >>>>>>>
> >>>>>>> On Fri, Nov 27, 2015 at 12:40 PM, Marius Dumitru Florea <
> >>>>>>> [hidden email]> wrote:
> >>>>>>>
> >>>>>>> On Thu, Nov 26, 2015 at 4:55 PM, Guillaume Lerouge
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>> Hi Devs,
> >>>>>>>>>
> >>>>>>>>> after trying XE 7.4 snapshot some more, I kept asking myself what
> >>>>>>>>>
> >>>>>>>> was the
> >>>>>>
> >>>>>>> point of even allowing terminal pages to exists. I couldn't see a
> >>>>>>>>>
> >>>>>>>> good
> >>>>>>
> >>>>>>> reason why any given page would *need* to be terminal, whereas it
> >>>>>>>>>
> >>>>>>>> poses
> >>>>>>
> >>>>>>> some issues:
> >>>>>>>>>
> >>>>>>>>> - There is no visual distinction between terminal pages and
> >>>>>>>>>
> >>>>>>>> nested
> >>>>
> >>>>> pages
> >>>>>>>>
> >>>>>>>>> in the interface (besides "WebHome" in the URL, which would be
> >>>>>>>>>
> >>>>>>>> cleaner
> >>>>>>
> >>>>>>> to
> >>>>>>>>> remove)
> >>>>>>>>> - We're planning to make it possible to reference a nested page
> >>>>>>>>>
> >>>>>>>> in
> >>>>
> >>>>> wiki
> >>>>>>>>
> >>>>>>>>> syntax without having to write "WebHome" in it
> >>>>>>>>> - When creating a new page from a terminal page, you're creating
> >>>>>>>>>
> >>>>>>>> a
> >>>>
> >>>>> sibling instead of a child page, which breaks the user
> >>>>>>>>>
> >>>>>>>> expectation
> >>>>
> >>>>> (and
> >>>>>>>>
> >>>>>>>>> the
> >>>>>>>>> breadcrumb)
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> - For AWM applications, data/content pages are created as
> >>>>>>>>>
> >>>>>>>> terminal
> >>>>
> >>>>> pages, which makes it impossible to add further content
> >>>>>>>>>
> >>>>>>>> underneath
> >>>>
> >>>>> them
> >>>>>>>>
> >>>>>>>>> in
> >>>>>>>>> the future (say, sub-tasks that would go as child pages of tasks)
> >>>>>>>>> - To my knowledge, there is no easy way to transform a terminal
> >>>>>>>>>
> >>>>>>>> page
> >>>>
> >>>>> into a nested page should the need arise later on
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> See
> >>>>>>>>
> >>>>>>> http://lists.xwiki.org/pipermail/users/2015-November/031558.html
> >>>>
> >>>>>
> >>>>>>>
> >>>>>>> Thanks. I understand it's fine to have terminal pages, but are they
> >>>>>>>
> >>>>>> really
> >>>>>>
> >>>>>>> *needed*?
> >>>>>>>
> >>>>>>> My feeling is that keeping this concept generates complexity for no
> >>>>>>>
> >>>>>> obvious
> >>>>>>
> >>>>>>> benefit.
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>> What really generates complexity ATM is the difference between the
> UI
> >>>>>> (Nested Pages) and the Model (Nested Spaces). I’d like to start a
> >>>>>>
> >>>>> design to
> >>>>
> >>>>> explore what options we have to remove the concept of Spaces in the
> >>>>>>
> >>>>> model
> >>>>
> >>>>> and only have pages. I have the feeling it’s going to be tough to not
> >>>>>>
> >>>>> break
> >>>>
> >>>>> everything but need to explore it to know our options.
> >>>>>>
> >>>>>> I feel that terminal pages are already well hidden in the UI so I’m
> >>>>>> not
> >>>>>> sure why you think we should remove it completely from the UI. Why
> do
> >>>>>>
> >>>>> you
> >>>>
> >>>>> fear that it’s too advanced for advanced users?
> >>>>>>
> >>>>>>
> >>>>> 2 reasons:
> >>>>>
> >>>>> *1/ Practical reason:* as a simple user, if I go to a terminal page
> and
> >>>>> create a page from there, I will create a sibling to the current page
> >>>>> instead of a child to the current page. I will not know why it
> happened
> >>>>> like this, nor will I have the ability to change it.
> >>>>>
> >>>>
> >>>> Right now users can already create sibling pages when they click the
> Add
> >>>> button on a page.
> >>>>
> >>>> It would be easy to add a small warning when you’re on a terminal page
> >>>> and
> >>>> you click Add to mention that this is a terminal page that cannot have
> >>>> children.
> >>>>
> >>>>
> >>> Right, a warning to simple users that something different than what
> they
> >>> expect is going to happen for a reason that they cannot fathom to begin
> >>> with since they don't even know about terminal pages in the first
> place.
> >>> It's a bit like telling them:
> >>>
> >>> *- XWiki: You can't create a child page from here!*
> >>> *- User: But, why?*
> >>> *- XWiki: Because!*
> >>> *- User: uh...*
> >>>
> >>> It only compounds the problem.
> >>>
> >>> *2/ Philosophical reason:* why keep something useless if we could as
> well
> >>>>
> >>>>> remove it? That would be an application of Ockham's razor principle
> if
> >>>>>
> >>>> you
> >>>>
> >>>>> will.
> >>>>>
> >>>>
> >>>> It’s not useless. As I mentioned this is still in the model and we
> still
> >>>> support it. This means that we need a way for advanced users to be
> able
> >>>> to
> >>>> create those pages (and using a script to do so is worse than having a
> >>>> nice
> >>>> UI for it).
> >>>>
> >>>>
> >>> I have the feeling we're running in circles here. Just because terminal
> >>> pages still exist in the model doesn't tell me *why* they're still
> needed
> >>> for the future.
> >>>
> >>> Do you have specific use cases in mind where it's *better* for an user
> >>> (or
> >>> a script!) to create a terminal page rather than a nested page? Does it
> >>> lead to performance improvements of some sort? Does it prevent
> backwards
> >>> compatibility issues that would be caused by switching all pages to
> >>> nested
> >>> pages? Any other *benefits* from having terminal pages?
> >>>
> >>
> >> I could list use cases (like some cases where it doesn’t make sense to
> >> have nested pages - like WebPreferences for example - Actually check a
> >> filesystem, you can’t create a subfile inside a file after all, I think
> >> users understand that) but anyway it doesn’t matter. The simple fact
> that
> >> we have terminal pages in lots of extensions require that the user be
> able
> >> to create terminal pages.
> >>
> >> Imagine that someone deletes a terminal page by error and you need to
> >> recreate it. You need a way to do that or your extension is not going to
> >> work.
> >>
> >> Thanks
> >> -Vincent
> >>
> >> Thanks,
> >>>
> >>> Guillaume
> >>>
> >>>
> >>> Thanks
> >>>> -Vincent
> >>>>
> >>>> Thanks,
> >>>>>
> >>>>> Guillaume
> >>>>>
> >>>>>
> >>>>> Thanks
> >>>>>> -Vincent
> >>>>>>
> >>>>>> Guillaume
> >>>>>>>
> >>>>>>>
> >>>>>>> - However, I don't see any problem from a page being a nested
> >>>>>>>>>
> >>>>>>>> page
> >>>>
> >>>>> instead of being a terminal page
> >>>>>>>>>
> >>>>>>>>> In summary: why bother with terminal pages at all? I understand
> >>>>>>>>>
> >>>>>>>> they're
> >>>>>>
> >>>>>>> an
> >>>>>>>>
> >>>>>>>>> artefact from our pre-nested-spaces model, but do they really
> >>>>>>>>>
> >>>>>>>> make
> >>>>
> >>>>> sense
> >>>>>>
> >>>>>>> now? We could let existing terminal pages live on, but not
> >>>>>>>>>
> >>>>>>>> remove the
> >>>>
> >>>>> ability to create new ones even for admins.
> >>>>>>>>>
> >>>>>>>>> Am I missing something obvious?
> >>>>>>>>>
> >>>>>>>>> Thanks,
> >>>>>>>>>
> >>>>>>>>> Guillaume
> >>>>>>>>>
> >>>>>>>> _______________________________________________
> >> devs mailing list
> >> [hidden email]
> >> http://lists.xwiki.org/mailman/listinfo/devs
> >>
> >> _______________________________________________
> > devs mailing list
> > [hidden email]
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Idea] Deprecate terminal pages

vmassol
Administrator
In reply to this post by Guillaume Lerouge
Hi Guillaume,

Several points:
* Terminal pages are already deprecated. Users create non terminal pages only.
* We need some migration scripts to let user migrate their existing content (using terminal pages) into non terminal pages
* Apps and extensions in general need to be updated to use non-terminal pages where it makes sense. Note that some apps may not want that users be able to create subpages to the data they create; it’s an app decision (sometimes it makes sense, sometimes it doesn’t).
* In order to full remove terminal pages we would need to modify the model at the DB level
* We need to handle legacy
* Terminal pages options are hidden in the rename/copy UIs and they shouldn’t generate WTF moments normally. If they do we need to tune that.

Thanks
-Vincent

On 15 Dec 2015 at 21:23:45, Guillaume Lerouge ([hidden email]) wrote:

Hi Devs,

another observation regarding this. Earlier today I watched a new user who
was trying XWiki 7.3. He had created a number of pages as terminal pages.
Then he tried to move some pages from their existing location to another
location, using the tree.

Unfortunately, several times, when trying to drop the page under an
existing page, a "cancel" icon was displayed when he tried to click on the
"Select" button. Of course the reason was that he was trying to drop his
page under a terminal page, but there was no explanation about this in the
UI. It also took me a while to figure things out :-)

All in all that was a very frustrating experience to watch. To me, that's
another reason why I think we should really look at how we could deprecate
terminal pages. I see them being the source of many misunderstandings and
additional issues like this one.

Thanks,

Guillaume

On Fri, Nov 27, 2015 at 5:27 PM, Caleb James DeLisle <[hidden email]> wrote:

> I can't imagine how I would attempt to explain a terminal (but not meaning
> it's going to die soon)
> page to someone who doesn't know the insides of the sausage factory.
>
> Every page is like a file, and it's also like a folder because it can have
> pages inside of it,
> except for the ones that can't...
>
> So +1 that users should never see/create/edit these weird pages which
> cannot have children.
>
> Thanks,
> Caleb
>
>
>
> On 27/11/15 17:10, [hidden email] wrote:
>
>>
>>
>>
>>
>>
>> On 27 Nov 2015 at 17:06:17, Guillaume Lerouge ([hidden email]
>> (mailto:[hidden email])) wrote:
>>
>> Hi Vincent,
>>>
>>> On Fri, Nov 27, 2015 at 4:53 PM, [hidden email]
>>> wrote:
>>>
>>>
>>>>
>>>>
>>>> On 27 Nov 2015 at 16:42:39, Guillaume Lerouge ([hidden email]
>>>> (mailto:
>>>> [hidden email])) wrote:
>>>>
>>>> Hi,
>>>>>
>>>>> Hi Marius,
>>>>>>
>>>>>>>
>>>>>>> On Fri, Nov 27, 2015 at 12:40 PM, Marius Dumitru Florea <
>>>>>>> [hidden email]> wrote:
>>>>>>>
>>>>>>> On Thu, Nov 26, 2015 at 4:55 PM, Guillaume Lerouge
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi Devs,
>>>>>>>>>
>>>>>>>>> after trying XE 7.4 snapshot some more, I kept asking myself what
>>>>>>>>>
>>>>>>>> was the
>>>>>>
>>>>>>> point of even allowing terminal pages to exists. I couldn't see a
>>>>>>>>>
>>>>>>>> good
>>>>>>
>>>>>>> reason why any given page would *need* to be terminal, whereas it
>>>>>>>>>
>>>>>>>> poses
>>>>>>
>>>>>>> some issues:
>>>>>>>>>
>>>>>>>>> - There is no visual distinction between terminal pages and
>>>>>>>>>
>>>>>>>> nested
>>>>
>>>>> pages
>>>>>>>>
>>>>>>>>> in the interface (besides "WebHome" in the URL, which would be
>>>>>>>>>
>>>>>>>> cleaner
>>>>>>
>>>>>>> to
>>>>>>>>> remove)
>>>>>>>>> - We're planning to make it possible to reference a nested page
>>>>>>>>>
>>>>>>>> in
>>>>
>>>>> wiki
>>>>>>>>
>>>>>>>>> syntax without having to write "WebHome" in it
>>>>>>>>> - When creating a new page from a terminal page, you're creating
>>>>>>>>>
>>>>>>>> a
>>>>
>>>>> sibling instead of a child page, which breaks the user
>>>>>>>>>
>>>>>>>> expectation
>>>>
>>>>> (and
>>>>>>>>
>>>>>>>>> the
>>>>>>>>> breadcrumb)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> - For AWM applications, data/content pages are created as
>>>>>>>>>
>>>>>>>> terminal
>>>>
>>>>> pages, which makes it impossible to add further content
>>>>>>>>>
>>>>>>>> underneath
>>>>
>>>>> them
>>>>>>>>
>>>>>>>>> in
>>>>>>>>> the future (say, sub-tasks that would go as child pages of tasks)
>>>>>>>>> - To my knowledge, there is no easy way to transform a terminal
>>>>>>>>>
>>>>>>>> page
>>>>
>>>>> into a nested page should the need arise later on
>>>>>>>>>
>>>>>>>>>
>>>>>>>> See
>>>>>>>>
>>>>>>> http://lists.xwiki.org/pipermail/users/2015-November/031558.html
>>>>
>>>>>
>>>>>>>
>>>>>>> Thanks. I understand it's fine to have terminal pages, but are they
>>>>>>>
>>>>>> really
>>>>>>
>>>>>>> *needed*?
>>>>>>>
>>>>>>> My feeling is that keeping this concept generates complexity for no
>>>>>>>
>>>>>> obvious
>>>>>>
>>>>>>> benefit.
>>>>>>>
>>>>>>
>>>>>>
>>>>>> What really generates complexity ATM is the difference between the UI
>>>>>> (Nested Pages) and the Model (Nested Spaces). I’d like to start a
>>>>>>
>>>>> design to
>>>>
>>>>> explore what options we have to remove the concept of Spaces in the
>>>>>>
>>>>> model
>>>>
>>>>> and only have pages. I have the feeling it’s going to be tough to not
>>>>>>
>>>>> break
>>>>
>>>>> everything but need to explore it to know our options.
>>>>>>
>>>>>> I feel that terminal pages are already well hidden in the UI so I’m
>>>>>> not
>>>>>> sure why you think we should remove it completely from the UI. Why do
>>>>>>
>>>>> you
>>>>
>>>>> fear that it’s too advanced for advanced users?
>>>>>>
>>>>>>
>>>>> 2 reasons:
>>>>>
>>>>> *1/ Practical reason:* as a simple user, if I go to a terminal page and
>>>>> create a page from there, I will create a sibling to the current page
>>>>> instead of a child to the current page. I will not know why it happened
>>>>> like this, nor will I have the ability to change it.
>>>>>
>>>>
>>>> Right now users can already create sibling pages when they click the Add
>>>> button on a page.
>>>>
>>>> It would be easy to add a small warning when you’re on a terminal page
>>>> and
>>>> you click Add to mention that this is a terminal page that cannot have
>>>> children.
>>>>
>>>>
>>> Right, a warning to simple users that something different than what they
>>> expect is going to happen for a reason that they cannot fathom to begin
>>> with since they don't even know about terminal pages in the first place.
>>> It's a bit like telling them:
>>>
>>> *- XWiki: You can't create a child page from here!*
>>> *- User: But, why?*
>>> *- XWiki: Because!*
>>> *- User: uh...*
>>>
>>> It only compounds the problem.
>>>
>>> *2/ Philosophical reason:* why keep something useless if we could as well
>>>>
>>>>> remove it? That would be an application of Ockham's razor principle if
>>>>>
>>>> you
>>>>
>>>>> will.
>>>>>
>>>>
>>>> It’s not useless. As I mentioned this is still in the model and we still
>>>> support it. This means that we need a way for advanced users to be able
>>>> to
>>>> create those pages (and using a script to do so is worse than having a
>>>> nice
>>>> UI for it).
>>>>
>>>>
>>> I have the feeling we're running in circles here. Just because terminal
>>> pages still exist in the model doesn't tell me *why* they're still needed
>>> for the future.
>>>
>>> Do you have specific use cases in mind where it's *better* for an user
>>> (or
>>> a script!) to create a terminal page rather than a nested page? Does it
>>> lead to performance improvements of some sort? Does it prevent backwards
>>> compatibility issues that would be caused by switching all pages to
>>> nested
>>> pages? Any other *benefits* from having terminal pages?
>>>
>>
>> I could list use cases (like some cases where it doesn’t make sense to
>> have nested pages - like WebPreferences for example - Actually check a
>> filesystem, you can’t create a subfile inside a file after all, I think
>> users understand that) but anyway it doesn’t matter. The simple fact that
>> we have terminal pages in lots of extensions require that the user be able
>> to create terminal pages.
>>
>> Imagine that someone deletes a terminal page by error and you need to
>> recreate it. You need a way to do that or your extension is not going to
>> work.
>>
>> Thanks
>> -Vincent
>>
>> Thanks,
>>>
>>> Guillaume
>>>
>>>
>>> Thanks
>>>> -Vincent
>>>>
>>>> Thanks,
>>>>>
>>>>> Guillaume
>>>>>
>>>>>
>>>>> Thanks
>>>>>> -Vincent
>>>>>>
>>>>>> Guillaume
>>>>>>>
>>>>>>>
>>>>>>> - However, I don't see any problem from a page being a nested
>>>>>>>>>
>>>>>>>> page
>>>>
>>>>> instead of being a terminal page
>>>>>>>>>
>>>>>>>>> In summary: why bother with terminal pages at all? I understand
>>>>>>>>>
>>>>>>>> they're
>>>>>>
>>>>>>> an
>>>>>>>>
>>>>>>>>> artefact from our pre-nested-spaces model, but do they really
>>>>>>>>>
>>>>>>>> make
>>>>
>>>>> sense
>>>>>>
>>>>>>> now? We could let existing terminal pages live on, but not
>>>>>>>>>
>>>>>>>> remove the
>>>>
>>>>> ability to create new ones even for admins.
>>>>>>>>>
>>>>>>>>> Am I missing something obvious?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Guillaume
>>>>>>>>>
>>>>>>>> _______________________________________________
>> devs mailing list
>> [hidden email]
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
>> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

[Brainstorming] Issue about being advanced user when testing XWiki (was Re: [Idea] Deprecate terminal pages)

vmassol
Administrator
In reply to this post by Marius Dumitru Florea


On 16 Dec 2015 at 07:14:31, Marius Dumitru Florea ([hidden email](mailto:[hidden email])) wrote:

> On Tue, Dec 15, 2015 at 10:23 PM, Guillaume Lerouge  
> wrote:
>  
> > Hi Devs,
> >
> > another observation regarding this. Earlier today I watched a new user who
> > was trying XWiki 7.3. He had created a number of pages as terminal pages.
> >
>  
> Did he use the default Admin profile (which is configured as advanced) or
> did he register a new profile (which is not advanced unless you configure
> it explicitly)? The default Admin profile is not the best way to test XWiki
> if you are a simple user.

Note that anyone trying XWiki will use the Admin user ATM since that’s the only user we provide by default and we even tell users to log with this user in the installation instructions… :)

To fix this we could ask the user to create both an admin and a user in a DW step. Or make the admin a simple user by default.

Thanks
-Vincent

[snip]

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

Re: [Brainstorming] Issue about being advanced user when testing XWiki (was Re: [Idea] Deprecate terminal pages)

Ecaterina Moraru (Valica)
Hi,

Having an user called 'Admin' is something that might be preserved. Maybe
changing the password, but besides that there is no point in deleting the
user.
Having an user called 'User' is not 'personal' enough and I'm not sure if
someone would keep and use this kind of user, after the initial log-in.

So in the Installation Notes, we could promote the Admin user for
Administrator's notes, while encouraging the registration of new user in
the Getting Started guide.
The disadvantage of registering when just testing XWiki is that it takes
longer. Ideally we should have social login that creates simple user types.

For automated tests we would need a simple user and create tests with
simple flows.

Another solution would be to make the displaying of Create terminal pages
check box disabled by default. So advanced Admin user would need to go to
their profile page and activate it, just like we have for "Display Hidden".

Thanks,
Caty




On Wed, Dec 16, 2015 at 11:07 AM, [hidden email] <[hidden email]>
wrote:

>
>
> On 16 Dec 2015 at 07:14:31, Marius Dumitru Florea (
> [hidden email](mailto:[hidden email]))
> wrote:
>
> > On Tue, Dec 15, 2015 at 10:23 PM, Guillaume Lerouge
> > wrote:
> >
> > > Hi Devs,
> > >
> > > another observation regarding this. Earlier today I watched a new user
> who
> > > was trying XWiki 7.3. He had created a number of pages as terminal
> pages.
> > >
> >
> > Did he use the default Admin profile (which is configured as advanced) or
> > did he register a new profile (which is not advanced unless you configure
> > it explicitly)? The default Admin profile is not the best way to test
> XWiki
> > if you are a simple user.
>
> Note that anyone trying XWiki will use the Admin user ATM since that’s the
> only user we provide by default and we even tell users to log with this
> user in the installation instructions… :)
>
> To fix this we could ask the user to create both an admin and a user in a
> DW step. Or make the admin a simple user by default.
>
> Thanks
> -Vincent
>
> [snip]
>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Brainstorming] Issue about being advanced user when testing XWiki (was Re: [Idea] Deprecate terminal pages)

vmassol
Administrator
Hi Caty,

On 16 Dec 2015 at 10:20:18, Ecaterina Moraru (Valica) ([hidden email](mailto:[hidden email])) wrote:

> Hi,
>  
> Having an user called 'Admin' is something that might be preserved. Maybe
> changing the password, but besides that there is no point in deleting the
> user.
> Having an user called 'User' is not 'personal' enough and I'm not sure if
> someone would keep and use this kind of user, after the initial log-in.

I don’t know who suggested creating a user called “User” :) That would be bad idea I agree.

> So in the Installation Notes, we could promote the Admin user for
> Administrator's notes, while encouraging the registration of new user in
> the Getting Started guide.

That’s not enough. Nobody reads install notes or guides. IMO it’s better to have it done in the DW. If you check how you install OSes, they ask you to create a user as part of the process. That seems the nicest as an install flow.

> The disadvantage of registering when just testing XWiki is that it takes
> longer. Ideally we should have social login that creates simple user types.

Social login is interesting too but it’s far from being the main use case. I’d say it corresponds to 5% of XWiki use cases since XWiki is an enterprise wiki and you install it on premises and don’t make it a public site in general. And you don’t want your employees to use social logins in lots of cases.

> For automated tests we would need a simple user and create tests with
> simple flows.

We do that already in several places.

> Another solution would be to make the displaying of Create terminal pages
> check box disabled by default. So advanced Admin user would need to go to
> their profile page and activate it, just like we have for "Display Hidden”.

Yes that could be an option but I’m not sure yet if it makes sense. The real question is whether Admins need to be able to create terminal pages or not as part of their job. If the answer is no then your solution could make sense.

Thanks
-Vincent

> Thanks,
> Caty
>  
>  
>  
>  
> On Wed, Dec 16, 2015 at 11:07 AM, [hidden email]  
> wrote:
>  
> >
> >
> > On 16 Dec 2015 at 07:14:31, Marius Dumitru Florea (
> > [hidden email](mailto:[hidden email]))
> > wrote:
> >
> > > On Tue, Dec 15, 2015 at 10:23 PM, Guillaume Lerouge
> > > wrote:
> > >
> > > > Hi Devs,
> > > >
> > > > another observation regarding this. Earlier today I watched a new user
> > who
> > > > was trying XWiki 7.3. He had created a number of pages as terminal
> > pages.
> > > >
> > >
> > > Did he use the default Admin profile (which is configured as advanced) or
> > > did he register a new profile (which is not advanced unless you configure
> > > it explicitly)? The default Admin profile is not the best way to test
> > XWiki
> > > if you are a simple user.
> >
> > Note that anyone trying XWiki will use the Admin user ATM since that’s the
> > only user we provide by default and we even tell users to log with this
> > user in the installation instructions… :)
> >
> > To fix this we could ask the user to create both an admin and a user in a
> > DW step. Or make the admin a simple user by default.
> >
> > Thanks
> > -Vincent
> >
> > [snip]
> >
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Idea] Deprecate terminal pages

Marius Dumitru Florea
In reply to this post by Marius Dumitru Florea
On Wed, Dec 16, 2015 at 8:14 AM, Marius Dumitru Florea <
[hidden email]> wrote:

> On Tue, Dec 15, 2015 at 10:23 PM, Guillaume Lerouge <[hidden email]>
> wrote:
>
>> Hi Devs,
>>
>> another observation regarding this. Earlier today I watched a new user who
>> was trying XWiki 7.3. He had created a number of pages as terminal pages.
>>
>
> Did he use the default Admin profile (which is configured as advanced) or
> did he register a new profile (which is not advanced unless you configure
> it explicitly)? The default Admin profile is not the best way to test XWiki
> if you are a simple user.
>
>
>> Then he tried to move some pages from their existing location to another
>> location, using the tree.
>>
>
> You mean using the Rename Page action, selecting the new location using
> the tree? As in
> http://platform.xwiki.org/xwiki/bin/view/Features/DocumentLifecycle#HMove2FRename
> .
>
>
>>
>> Unfortunately, several times, when trying to drop the page under an
>> existing page, a "cancel" icon was displayed when he tried to click on the
>> "Select" button. Of course the reason was that he was trying to drop his
>> page under a terminal page, but there was no explanation about this in the
>> UI. It also took me a while to figure things out :-)
>>
>
>

> The tree from the Rename Page UI doesn't show terminal pages and doesn't
> support drag&drop. The "Select" button from the "Select Page" modal popup
> that displays the tree is disabled when there is no page selected in the
> tree. So I don't understand what you are talking about.
>

FTR, I talked with Guillaume in private and he showed me the wiki where he
had the problem. The issue was that he imported the Document Tree Macro
pages by mistake from an older XWiki version (pre nested pages) which has
affected the tree displayed on the Rename Page UI.


>
> Thanks,
> Marius
>
>
>>
>> All in all that was a very frustrating experience to watch. To me, that's
>> another reason why I think we should really look at how we could deprecate
>> terminal pages. I see them being the source of many misunderstandings and
>> additional issues like this one.
>>
>> Thanks,
>>
>> Guillaume
>>
>> On Fri, Nov 27, 2015 at 5:27 PM, Caleb James DeLisle <[hidden email]>
>> wrote:
>>
>> > I can't imagine how I would attempt to explain a terminal (but not
>> meaning
>> > it's going to die soon)
>> > page to someone who doesn't know the insides of the sausage factory.
>> >
>> > Every page is like a file, and it's also like a folder because it can
>> have
>> > pages inside of it,
>> > except for the ones that can't...
>> >
>> > So +1 that users should never see/create/edit these weird pages which
>> > cannot have children.
>> >
>> > Thanks,
>> > Caleb
>> >
>> >
>> >
>> > On 27/11/15 17:10, [hidden email] wrote:
>> >
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> On 27 Nov 2015 at 17:06:17, Guillaume Lerouge ([hidden email]
>> >> (mailto:[hidden email])) wrote:
>> >>
>> >> Hi Vincent,
>> >>>
>> >>> On Fri, Nov 27, 2015 at 4:53 PM, [hidden email]
>> >>> wrote:
>> >>>
>> >>>
>> >>>>
>> >>>>
>> >>>> On 27 Nov 2015 at 16:42:39, Guillaume Lerouge ([hidden email]
>> >>>> (mailto:
>> >>>> [hidden email])) wrote:
>> >>>>
>> >>>> Hi,
>> >>>>>
>> >>>>> Hi Marius,
>> >>>>>>
>> >>>>>>>
>> >>>>>>> On Fri, Nov 27, 2015 at 12:40 PM, Marius Dumitru Florea <
>> >>>>>>> [hidden email]> wrote:
>> >>>>>>>
>> >>>>>>> On Thu, Nov 26, 2015 at 4:55 PM, Guillaume Lerouge
>> >>>>>>>> wrote:
>> >>>>>>>>
>> >>>>>>>> Hi Devs,
>> >>>>>>>>>
>> >>>>>>>>> after trying XE 7.4 snapshot some more, I kept asking myself
>> what
>> >>>>>>>>>
>> >>>>>>>> was the
>> >>>>>>
>> >>>>>>> point of even allowing terminal pages to exists. I couldn't see a
>> >>>>>>>>>
>> >>>>>>>> good
>> >>>>>>
>> >>>>>>> reason why any given page would *need* to be terminal, whereas it
>> >>>>>>>>>
>> >>>>>>>> poses
>> >>>>>>
>> >>>>>>> some issues:
>> >>>>>>>>>
>> >>>>>>>>> - There is no visual distinction between terminal pages and
>> >>>>>>>>>
>> >>>>>>>> nested
>> >>>>
>> >>>>> pages
>> >>>>>>>>
>> >>>>>>>>> in the interface (besides "WebHome" in the URL, which would be
>> >>>>>>>>>
>> >>>>>>>> cleaner
>> >>>>>>
>> >>>>>>> to
>> >>>>>>>>> remove)
>> >>>>>>>>> - We're planning to make it possible to reference a nested page
>> >>>>>>>>>
>> >>>>>>>> in
>> >>>>
>> >>>>> wiki
>> >>>>>>>>
>> >>>>>>>>> syntax without having to write "WebHome" in it
>> >>>>>>>>> - When creating a new page from a terminal page, you're creating
>> >>>>>>>>>
>> >>>>>>>> a
>> >>>>
>> >>>>> sibling instead of a child page, which breaks the user
>> >>>>>>>>>
>> >>>>>>>> expectation
>> >>>>
>> >>>>> (and
>> >>>>>>>>
>> >>>>>>>>> the
>> >>>>>>>>> breadcrumb)
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>> - For AWM applications, data/content pages are created as
>> >>>>>>>>>
>> >>>>>>>> terminal
>> >>>>
>> >>>>> pages, which makes it impossible to add further content
>> >>>>>>>>>
>> >>>>>>>> underneath
>> >>>>
>> >>>>> them
>> >>>>>>>>
>> >>>>>>>>> in
>> >>>>>>>>> the future (say, sub-tasks that would go as child pages of
>> tasks)
>> >>>>>>>>> - To my knowledge, there is no easy way to transform a terminal
>> >>>>>>>>>
>> >>>>>>>> page
>> >>>>
>> >>>>> into a nested page should the need arise later on
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>> See
>> >>>>>>>>
>> >>>>>>> http://lists.xwiki.org/pipermail/users/2015-November/031558.html
>> >>>>
>> >>>>>
>> >>>>>>>
>> >>>>>>> Thanks. I understand it's fine to have terminal pages, but are
>> they
>> >>>>>>>
>> >>>>>> really
>> >>>>>>
>> >>>>>>> *needed*?
>> >>>>>>>
>> >>>>>>> My feeling is that keeping this concept generates complexity for
>> no
>> >>>>>>>
>> >>>>>> obvious
>> >>>>>>
>> >>>>>>> benefit.
>> >>>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> What really generates complexity ATM is the difference between the
>> UI
>> >>>>>> (Nested Pages) and the Model (Nested Spaces). I’d like to start a
>> >>>>>>
>> >>>>> design to
>> >>>>
>> >>>>> explore what options we have to remove the concept of Spaces in the
>> >>>>>>
>> >>>>> model
>> >>>>
>> >>>>> and only have pages. I have the feeling it’s going to be tough to
>> not
>> >>>>>>
>> >>>>> break
>> >>>>
>> >>>>> everything but need to explore it to know our options.
>> >>>>>>
>> >>>>>> I feel that terminal pages are already well hidden in the UI so I’m
>> >>>>>> not
>> >>>>>> sure why you think we should remove it completely from the UI. Why
>> do
>> >>>>>>
>> >>>>> you
>> >>>>
>> >>>>> fear that it’s too advanced for advanced users?
>> >>>>>>
>> >>>>>>
>> >>>>> 2 reasons:
>> >>>>>
>> >>>>> *1/ Practical reason:* as a simple user, if I go to a terminal page
>> and
>> >>>>> create a page from there, I will create a sibling to the current
>> page
>> >>>>> instead of a child to the current page. I will not know why it
>> happened
>> >>>>> like this, nor will I have the ability to change it.
>> >>>>>
>> >>>>
>> >>>> Right now users can already create sibling pages when they click the
>> Add
>> >>>> button on a page.
>> >>>>
>> >>>> It would be easy to add a small warning when you’re on a terminal
>> page
>> >>>> and
>> >>>> you click Add to mention that this is a terminal page that cannot
>> have
>> >>>> children.
>> >>>>
>> >>>>
>> >>> Right, a warning to simple users that something different than what
>> they
>> >>> expect is going to happen for a reason that they cannot fathom to
>> begin
>> >>> with since they don't even know about terminal pages in the first
>> place.
>> >>> It's a bit like telling them:
>> >>>
>> >>> *- XWiki: You can't create a child page from here!*
>> >>> *- User: But, why?*
>> >>> *- XWiki: Because!*
>> >>> *- User: uh...*
>> >>>
>> >>> It only compounds the problem.
>> >>>
>> >>> *2/ Philosophical reason:* why keep something useless if we could as
>> well
>> >>>>
>> >>>>> remove it? That would be an application of Ockham's razor principle
>> if
>> >>>>>
>> >>>> you
>> >>>>
>> >>>>> will.
>> >>>>>
>> >>>>
>> >>>> It’s not useless. As I mentioned this is still in the model and we
>> still
>> >>>> support it. This means that we need a way for advanced users to be
>> able
>> >>>> to
>> >>>> create those pages (and using a script to do so is worse than having
>> a
>> >>>> nice
>> >>>> UI for it).
>> >>>>
>> >>>>
>> >>> I have the feeling we're running in circles here. Just because
>> terminal
>> >>> pages still exist in the model doesn't tell me *why* they're still
>> needed
>> >>> for the future.
>> >>>
>> >>> Do you have specific use cases in mind where it's *better* for an user
>> >>> (or
>> >>> a script!) to create a terminal page rather than a nested page? Does
>> it
>> >>> lead to performance improvements of some sort? Does it prevent
>> backwards
>> >>> compatibility issues that would be caused by switching all pages to
>> >>> nested
>> >>> pages? Any other *benefits* from having terminal pages?
>> >>>
>> >>
>> >> I could list use cases (like some cases where it doesn’t make sense to
>> >> have nested pages - like WebPreferences for example - Actually check a
>> >> filesystem, you can’t create a subfile inside a file after all, I think
>> >> users understand that) but anyway it doesn’t matter. The simple fact
>> that
>> >> we have terminal pages in lots of extensions require that the user be
>> able
>> >> to create terminal pages.
>> >>
>> >> Imagine that someone deletes a terminal page by error and you need to
>> >> recreate it. You need a way to do that or your extension is not going
>> to
>> >> work.
>> >>
>> >> Thanks
>> >> -Vincent
>> >>
>> >> Thanks,
>> >>>
>> >>> Guillaume
>> >>>
>> >>>
>> >>> Thanks
>> >>>> -Vincent
>> >>>>
>> >>>> Thanks,
>> >>>>>
>> >>>>> Guillaume
>> >>>>>
>> >>>>>
>> >>>>> Thanks
>> >>>>>> -Vincent
>> >>>>>>
>> >>>>>> Guillaume
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> - However, I don't see any problem from a page being a nested
>> >>>>>>>>>
>> >>>>>>>> page
>> >>>>
>> >>>>> instead of being a terminal page
>> >>>>>>>>>
>> >>>>>>>>> In summary: why bother with terminal pages at all? I understand
>> >>>>>>>>>
>> >>>>>>>> they're
>> >>>>>>
>> >>>>>>> an
>> >>>>>>>>
>> >>>>>>>>> artefact from our pre-nested-spaces model, but do they really
>> >>>>>>>>>
>> >>>>>>>> make
>> >>>>
>> >>>>> sense
>> >>>>>>
>> >>>>>>> now? We could let existing terminal pages live on, but not
>> >>>>>>>>>
>> >>>>>>>> remove the
>> >>>>
>> >>>>> ability to create new ones even for admins.
>> >>>>>>>>>
>> >>>>>>>>> Am I missing something obvious?
>> >>>>>>>>>
>> >>>>>>>>> Thanks,
>> >>>>>>>>>
>> >>>>>>>>> Guillaume
>> >>>>>>>>>
>> >>>>>>>> _______________________________________________
>> >> devs mailing list
>> >> [hidden email]
>> >> http://lists.xwiki.org/mailman/listinfo/devs
>> >>
>> >> _______________________________________________
>> > devs mailing list
>> > [hidden email]
>> > http://lists.xwiki.org/mailman/listinfo/devs
>> >
>> _______________________________________________
>> devs mailing list
>> [hidden email]
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
>
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Brainstorming] Issue about being advanced user when testing XWiki (was Re: [Idea] Deprecate terminal pages)

Marius Dumitru Florea
In reply to this post by vmassol
On Wed, Dec 16, 2015 at 11:07 AM, [hidden email] <[hidden email]>
wrote:

>
>
> On 16 Dec 2015 at 07:14:31, Marius Dumitru Florea (
> [hidden email](mailto:[hidden email]))
> wrote:
>
> > On Tue, Dec 15, 2015 at 10:23 PM, Guillaume Lerouge
> > wrote:
> >
> > > Hi Devs,
> > >
> > > another observation regarding this. Earlier today I watched a new user
> who
> > > was trying XWiki 7.3. He had created a number of pages as terminal
> pages.
> > >
> >
> > Did he use the default Admin profile (which is configured as advanced) or
> > did he register a new profile (which is not advanced unless you configure
> > it explicitly)? The default Admin profile is not the best way to test
> XWiki
> > if you are a simple user.
>
> Note that anyone trying XWiki will use the Admin user ATM since that’s the
> only user we provide by default and we even tell users to log with this
> user in the installation instructions… :)
>
>

> To fix this we could ask the user to create both an admin and a user in a
> DW step. Or make the admin a simple user by default.
>

+1 for creating the user profile during the DW, but how do we justify the
creation of two profiles: an admin and a simple user? If we create just a
single user profile then it probably needs to be advanced because it will
be used by the user that installs the wiki, which is going to administrate
the wiki also.

The problem is, as Guillaume Lerouge pointed out in a private discussion
this morning, that people who test XWiki are usually going to be the
administrator of their wiki instance and so they want to see Access Rights,
they want to see groups etc. (i.e. all the advanced features).

Thanks,
Marius


>
> Thanks
> -Vincent
>
> [snip]
>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Brainstorming] Issue about being advanced user when testing XWiki (was Re: [Idea] Deprecate terminal pages)

Thomas Mortagne
Administrator
What we need to do is ask the login/password of his user the first
time and make him administrator. Have some user called XWiki.Admin is
totally useless.

On Wed, Dec 16, 2015 at 2:24 PM, Marius Dumitru Florea
<[hidden email]> wrote:

> On Wed, Dec 16, 2015 at 11:07 AM, [hidden email] <[hidden email]>
> wrote:
>
>>
>>
>> On 16 Dec 2015 at 07:14:31, Marius Dumitru Florea (
>> [hidden email](mailto:[hidden email]))
>> wrote:
>>
>> > On Tue, Dec 15, 2015 at 10:23 PM, Guillaume Lerouge
>> > wrote:
>> >
>> > > Hi Devs,
>> > >
>> > > another observation regarding this. Earlier today I watched a new user
>> who
>> > > was trying XWiki 7.3. He had created a number of pages as terminal
>> pages.
>> > >
>> >
>> > Did he use the default Admin profile (which is configured as advanced) or
>> > did he register a new profile (which is not advanced unless you configure
>> > it explicitly)? The default Admin profile is not the best way to test
>> XWiki
>> > if you are a simple user.
>>
>> Note that anyone trying XWiki will use the Admin user ATM since that’s the
>> only user we provide by default and we even tell users to log with this
>> user in the installation instructions… :)
>>
>>
>
>> To fix this we could ask the user to create both an admin and a user in a
>> DW step. Or make the admin a simple user by default.
>>
>
> +1 for creating the user profile during the DW, but how do we justify the
> creation of two profiles: an admin and a simple user? If we create just a
> single user profile then it probably needs to be advanced because it will
> be used by the user that installs the wiki, which is going to administrate
> the wiki also.
>
> The problem is, as Guillaume Lerouge pointed out in a private discussion
> this morning, that people who test XWiki are usually going to be the
> administrator of their wiki instance and so they want to see Access Rights,
> they want to see groups etc. (i.e. all the advanced features).
>
> Thanks,
> Marius
>
>
>>
>> Thanks
>> -Vincent
>>
>> [snip]
>>
>> _______________________________________________
>> devs mailing list
>> [hidden email]
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs



--
Thomas Mortagne
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Brainstorming] Issue about being advanced user when testing XWiki (was Re: [Idea] Deprecate terminal pages)

Guillaume Lerouge
In reply to this post by vmassol
Hi,

sorry for the late reply.

On Wed, Dec 16, 2015 at 10:27 AM, [hidden email] <[hidden email]>
wrote:

> Hi Caty,
>
> On 16 Dec 2015 at 10:20:18, Ecaterina Moraru (Valica) ([hidden email]
> (mailto:[hidden email])) wrote:
>
> > Hi,
> >
> > Having an user called 'Admin' is something that might be preserved. Maybe
> > changing the password, but besides that there is no point in deleting the
> > user.
> > Having an user called 'User' is not 'personal' enough and I'm not sure if
> > someone would keep and use this kind of user, after the initial log-in.
>
> I don’t know who suggested creating a user called “User” :) That would be
> bad idea I agree.
>
> > So in the Installation Notes, we could promote the Admin user for
> > Administrator's notes, while encouraging the registration of new user in
> > the Getting Started guide.
>
> That’s not enough. Nobody reads install notes or guides. IMO it’s better
> to have it done in the DW. If you check how you install OSes, they ask you
> to create a user as part of the process. That seems the nicest as an
> install flow.
>
> > The disadvantage of registering when just testing XWiki is that it takes
> > longer. Ideally we should have social login that creates simple user
> types.
>
> Social login is interesting too but it’s far from being the main use case.
> I’d say it corresponds to 5% of XWiki use cases since XWiki is an
> enterprise wiki and you install it on premises and don’t make it a public
> site in general. And you don’t want your employees to use social logins in
> lots of cases.
>
> > For automated tests we would need a simple user and create tests with
> > simple flows.
>
> We do that already in several places.
>
> > Another solution would be to make the displaying of Create terminal pages
> > check box disabled by default. So advanced Admin user would need to go to
> > their profile page and activate it, just like we have for "Display
> Hidden”.
>
> Yes that could be an option but I’m not sure yet if it makes sense. The
> real question is whether Admins need to be able to create terminal pages or
> not as part of their job. If the answer is no then your solution could make
> sense.
>

For the record, I think this is a good idea.

Thanks,

Guillaume

Thanks

> -Vincent
>
> > Thanks,
> > Caty
> >
> >
> >
> >
> > On Wed, Dec 16, 2015 at 11:07 AM, [hidden email]
> > wrote:
> >
> > >
> > >
> > > On 16 Dec 2015 at 07:14:31, Marius Dumitru Florea (
> > > [hidden email](mailto:[hidden email]))
> > > wrote:
> > >
> > > > On Tue, Dec 15, 2015 at 10:23 PM, Guillaume Lerouge
> > > > wrote:
> > > >
> > > > > Hi Devs,
> > > > >
> > > > > another observation regarding this. Earlier today I watched a new
> user
> > > who
> > > > > was trying XWiki 7.3. He had created a number of pages as terminal
> > > pages.
> > > > >
> > > >
> > > > Did he use the default Admin profile (which is configured as
> advanced) or
> > > > did he register a new profile (which is not advanced unless you
> configure
> > > > it explicitly)? The default Admin profile is not the best way to test
> > > XWiki
> > > > if you are a simple user.
> > >
> > > Note that anyone trying XWiki will use the Admin user ATM since that’s
> the
> > > only user we provide by default and we even tell users to log with this
> > > user in the installation instructions… :)
> > >
> > > To fix this we could ask the user to create both an admin and a user
> in a
> > > DW step. Or make the admin a simple user by default.
> > >
> > > Thanks
> > > -Vincent
> > >
> > > [snip]
> > >
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
> <https://mailtrack.io/trace/link/bb2484bff5eeb048bda13ef460bda15b0523abfb?url=http%3A%2F%2Flists.xwiki.org%2Fmailman%2Flistinfo%2Fdevs&signature=ee3169b99362053e>
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs