PLIP: Remove default pages

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

PLIP: Remove default pages

Hi Team,

I need your advice. Something to ponder over the holiday period (for those parts of the world where this is a holiday period).
This is the folderish-content types proposal which I've renamed and broken down into three parts:
- Reduce reliance on default pages
- Introduce tiles into the visual editor
- Remove default pages from p.a.contenttypes
The first two can be implemented without breaking backwards compatibility.

I'd like to make it more approachable so the framework team are as enthusiastic as I am about it, and also to get some volunteers to help work on it.
Advice?


https://docs.google.com/a/pretaweb.com/document/d/1jJ7765rW-CpdOhKR6o4hFaOzQk6xmuePFZd-zTzxwFE/edit?pli=1#

Abstract
-----------

Remove the concepts of Folder, collection and default page from Plone, instead all content types will be folderish. This will make Plone easier to use and easier to learn.
This is partial step towards the full deco implementation. It includes replacing collections and folders with a single Page type. Tiles will be introduced however no grid system is introduced and the way content is edited and laid out doesn’t change. How titles, portlets, sharing and content rules are improved to include the “at this level only” functionality.

Motivation
--------------

The motivation is to make Plone more intuitive, require less training for first time users
and to reduce the effort of editing for experienced users. The concepts of default pages and folders are easy to understand if you move from editing static HTML websites but this is increasingly rare. There has general agreement from the UI team about the idea of remove default pages.
A recent survey (the Plone UX hitlist) showed that the concepts of default pages was one the leading UX hurdles with Plone.

        • #1 for Editors https://trello.com/c/HbWFnggT/26-not-obvious-how-to-edit-publish-folder-when-it-has-a-default-page
        • #2 for Editors https://trello.com/c/ryIsWRUm/31-no-out-of-the-box-way-to-include-listings-rich-content-repeated-content-into-the-text-of-a-page (if using folderpagetiles)
        • #3 for Editors https://trello.com/c/JYdgXfMK/2-idea-of-default-page-is-not-obvious
        • https://trello.com/c/7OS5ac9i/24-not-obvious-display-menu-changes-item-no-way-to-preview (if display menu moved into /edit)
        • https://trello.com/c/lV7a7lEM/56-navigation-being-tied-to-folder-structure-isn-t-obvious

Deco was about improving approachability and making it easier for users to create complex pages. This is a stepping stone towards the original deco idea. We think part of the reason Deco hasn’t yet happened is because its too large a change all at once. It’s both hard to implement and hard for people to accept as an improvement when the step is so large. Hopefully this proposal strikes the right balance of achievability, low risk and user acceptance.



Assumptions
----------------

We assume this change will require a major release. This change introduces backwards incompatibility. Ideally it would be in Plone 5 combined with the p.a.contenttypes upgrade. If it were delayed to Plone 6 we’d either have to wait too long for the usability benefits or we’d have two disruptive releases very close to each other prolonging the pain of upgrades.
It is a disruptive change for the following reasons
        • it changes the data structure of the content types
        • breaks third-party plugins using content types
        • changes the UX

We assume that it’s not the right time yet to introduce grid based layouts or tile based layouts to replace portlets and viewlets. The motivation for not going all the way to a full deco approach is that deco requires all themes to incorporate a single grid system and it’s not clear what that grid system would be or it’s a good idea for all themes to include a grid system.

The following functionality will be lost. We assume this will be OK.
        • have a different workflow for folders and pages
        • unpublish a default page while folder is published



Proposal & Implementation
-----------------------------------

This proposal can be broken down into three sub PLIPS. The first two can be implemented without breaking backwards compatibility.

Reduce reliance on default pages
~~~~~~~~~~~~~~~~~~~~~~~~
There are number of features of plone which rely on default pages. The following changes could be made before removing the default pages function.
        • When editing an object, allow for the title and description to be overridden for navigation (side nav, sitemap, top nav, breadcrumbs etc). This might need a new tab.  Could be implemented as a behaviour.
        • Change the manage portlets UI to set a portlet as being either for “this page”, “all pages” or “sub pages only”. This replaces the ability to have two sets of portlets at either the folder level or default page level.
        • Change the sharing UI to set a local role as being either for “this page” or “all pages” or “sub pages only”
        • Change the content rules assignment UI to set a rule assignment as being either for “this page” or “all pages” or “sub pages only”

Introduce tiles into the visual editor
~~~~~~~~~~~~~~~~~~~~~~~~~
TinyMCE will allow you to insert a tile into a richcontent field such as on a page type. Several out-of-the-box tiles would be supported including content listing (replacing the functionality of collections) and alias (replacing the functionality of using another content object as a default page, if the other content isn’t folderish). TinyMCE will represent the tile with a placeholder such as an image similar to collective.tinymcetiles. Additional styles might need to be introduced to set the width of a tile to 100%, 50% etc.
Optionally introduce a way to use tiles as portlets and viewlets. This will make the development story less confusing as a single way to development these components could be recommended.
An alternative proposal was considered which avoided the use of tiles, instead a combination Page/Collection/Folder type was proposed. Using tiles however has the added advantage that multiple collections can be represented on the same page, and an alias tile can help where 3rd party types aren’t yet folderish.

Remove default pages in p.a.contenttypes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Change plone.app.content types so all types are folderish.
        • The folder type and collection type will be removed and replaced with a single “Page” type.
        • Subpages are created by clicking “add new > page” on an existing page.
        • Automated listing of contents is achieved by inserting a listing tile via tinymce and choosing a query for the contents. Collections are done the same way. Sub-collections would be harder with no inheritance of criteria but still possible.
        • The “select as default page page” option will be removed
        • The root portal object will be like a Page. If editors can have an alias tile.
        • An upgrade step would be created to change the base class of existing p.a.content types objects. Folders would change into pages. Default pages would be merged with their folder. Collections would turned into pages with a single listing tile. In the case where the default page is 3rd party and can’t be made folderish the alias tile will be used.
        • Since the display menu will no longer be used for setting listing templates or default pages so there will be no out of the box display menu options left. It will be kept for backwards compatibility but it doesn’t need to be so prominent We propose moving it into the edit dialog. It would be helpful if it also had a preview mode.
        • After removing collections there will need to be a way of creating RSS feeds. We propose a RSS behaviour that adds a RSS query field to content. This will help make RSS more explicit in Plone as it’s currently a hidden feature. Alternatively a separate RSS content type could be created.
        • WebDAV will handle adding folders by creating Pages with a single contents listing tile.



Deliverables
----------------

Risks
-------
        • Incorporating tiles within tinymce without more use of collective.tinymcetiles poses some risk
        • Tiles themselves have been used in production via collective.cover however there could still be some risks involved.
        • There might existing other functionality that will be lost hasn’t yet been considered.
        • Caching settings have different rules for folderish and content-ish types. You normally don’t want strong caching on automated listing types. Need to work out if we no longer differentiate or perhaps have a way to distinguish content that as a listing tile added.


Dylan Jay

---
www.pretagov.com - Secure SaaS for Government hosted locally.
P: +61-2-9955-2830  +44-87-0392-7071 | linkedin.com/in/djay75



_______________________________________________
UI mailing list
[hidden email]
https://lists.plone.org/mailman/listinfo/plone-ui
Dylan Jay Dylan Jay
Reply | Threaded
Open this post in threaded view
|

Re: PLIP: Remove default pages

Hi,

Something specific I'd like feedback on is the change to the UI for sharing.

It currently looks like 
+-----------------+------------+---------------+--------------+---------------+
| Name            |  Can add   |   Can edit    |   Can review |   Can view    |
+-----------------+------------+---------------+--------------+---------------+
| User X          |    [ ]     |     [X]       |     [ ]      |     [ ]       |
+-----------------+------------+---------------+--------------+---------------+

However what we need to do is allow the user to share just the current page without giving sharing anything below it if we are to replace what default pages does.

We could do something like this

+-----------------+------------+---------------+--------------+---------------+
| Name            |  Can add   |   Can edit    |   Can review |   Can view    |
+-----------------+------------+---------------+--------------+---------------+
|                 |here | below| here  | below | here | below | here | below  |
+-----------------+------------+---------------+--------------+---------------+
| User X          | [ ] | [ ]  |  [X]  |  [ ]  | [ ]  |  [ ]  |  [ ] |  [ ]   |
+-----------------+------------+---------------+--------------+---------------+

or maybe with a drop down?

+-----------------+-------------------+------------------+--------------+---------------+
| Name            |  Can add          |   Can edit       |   Can review |   Can view    |
+-----------------+-------------------+--------+---------+----+-------------------------+
| User X          | [ here&below |v|] | [ here       |v|]| [        |v|]| [ below |v|]  |
+-----------------+------------+-------------------------+------------------------------+


Dylan Jay

---
www.pretagov.com - Secure SaaS for Government hosted locally.
P: +61-2-9955-2830  +44-87-0392-7071 | linkedin.com/in/djay75



On 24 Dec 2013, at 4:26 pm, Dylan Jay <[hidden email]> wrote:

Hi Team,

I need your advice. Something to ponder over the holiday period (for those parts of the world where this is a holiday period).
This is the folderish-content types proposal which I've renamed and broken down into three parts:
- Reduce reliance on default pages
- Introduce tiles into the visual editor
- Remove default pages from p.a.contenttypes
The first two can be implemented without breaking backwards compatibility.

I'd like to make it more approachable so the framework team are as enthusiastic as I am about it, and also to get some volunteers to help work on it.
Advice?


https://docs.google.com/a/pretaweb.com/document/d/1jJ7765rW-CpdOhKR6o4hFaOzQk6xmuePFZd-zTzxwFE/edit?pli=1#

Abstract
-----------

Remove the concepts of Folder, collection and default page from Plone, instead all content types will be folderish. This will make Plone easier to use and easier to learn.
This is partial step towards the full deco implementation. It includes replacing collections and folders with a single Page type. Tiles will be introduced however no grid system is introduced and the way content is edited and laid out doesn’t change. How titles, portlets, sharing and content rules are improved to include the “at this level only” functionality.

Motivation
--------------

The motivation is to make Plone more intuitive, require less training for first time users
and to reduce the effort of editing for experienced users. The concepts of default pages and folders are easy to understand if you move from editing static HTML websites but this is increasingly rare. There has general agreement from the UI team about the idea of remove default pages. 
A recent survey (the Plone UX hitlist) showed that the concepts of default pages was one the leading UX hurdles with Plone. 

• #1 for Editors https://trello.com/c/HbWFnggT/26-not-obvious-how-to-edit-publish-folder-when-it-has-a-default-page
• #2 for Editors https://trello.com/c/ryIsWRUm/31-no-out-of-the-box-way-to-include-listings-rich-content-repeated-content-into-the-text-of-a-page (if using folderpagetiles)
• #3 for Editors https://trello.com/c/JYdgXfMK/2-idea-of-default-page-is-not-obvious
• https://trello.com/c/7OS5ac9i/24-not-obvious-display-menu-changes-item-no-way-to-preview (if display menu moved into /edit)
• https://trello.com/c/lV7a7lEM/56-navigation-being-tied-to-folder-structure-isn-t-obvious

Deco was about improving approachability and making it easier for users to create complex pages. This is a stepping stone towards the original deco idea. We think part of the reason Deco hasn’t yet happened is because its too large a change all at once. It’s both hard to implement and hard for people to accept as an improvement when the step is so large. Hopefully this proposal strikes the right balance of achievability, low risk and user acceptance.



Assumptions
----------------

We assume this change will require a major release. This change introduces backwards incompatibility. Ideally it would be in Plone 5 combined with the p.a.contenttypes upgrade. If it were delayed to Plone 6 we’d either have to wait too long for the usability benefits or we’d have two disruptive releases very close to each other prolonging the pain of upgrades.
It is a disruptive change for the following reasons 
• it changes the data structure of the content types
• breaks third-party plugins using content types
• changes the UX

We assume that it’s not the right time yet to introduce grid based layouts or tile based layouts to replace portlets and viewlets. The motivation for not going all the way to a full deco approach is that deco requires all themes to incorporate a single grid system and it’s not clear what that grid system would be or it’s a good idea for all themes to include a grid system.

The following functionality will be lost. We assume this will be OK.
• have a different workflow for folders and pages
• unpublish a default page while folder is published



Proposal & Implementation
-----------------------------------

This proposal can be broken down into three sub PLIPS. The first two can be implemented without breaking backwards compatibility.

Reduce reliance on default pages
~~~~~~~~~~~~~~~~~~~~~~~~
There are number of features of plone which rely on default pages. The following changes could be made before removing the default pages function. 
• When editing an object, allow for the title and description to be overridden for navigation (side nav, sitemap, top nav, breadcrumbs etc). This might need a new tab.  Could be implemented as a behaviour. 
• Change the manage portlets UI to set a portlet as being either for “this page”, “all pages” or “sub pages only”. This replaces the ability to have two sets of portlets at either the folder level or default page level.
• Change the sharing UI to set a local role as being either for “this page” or “all pages” or “sub pages only”
• Change the content rules assignment UI to set a rule assignment as being either for “this page” or “all pages” or “sub pages only”

Introduce tiles into the visual editor
~~~~~~~~~~~~~~~~~~~~~~~~~
TinyMCE will allow you to insert a tile into a richcontent field such as on a page type. Several out-of-the-box tiles would be supported including content listing (replacing the functionality of collections) and alias (replacing the functionality of using another content object as a default page, if the other content isn’t folderish). TinyMCE will represent the tile with a placeholder such as an image similar to collective.tinymcetiles. Additional styles might need to be introduced to set the width of a tile to 100%, 50% etc.
Optionally introduce a way to use tiles as portlets and viewlets. This will make the development story less confusing as a single way to development these components could be recommended.
An alternative proposal was considered which avoided the use of tiles, instead a combination Page/Collection/Folder type was proposed. Using tiles however has the added advantage that multiple collections can be represented on the same page, and an alias tile can help where 3rd party types aren’t yet folderish.

Remove default pages in p.a.contenttypes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Change plone.app.content types so all types are folderish. 
• The folder type and collection type will be removed and replaced with a single “Page” type. 
• Subpages are created by clicking “add new > page” on an existing page. 
• Automated listing of contents is achieved by inserting a listing tile via tinymce and choosing a query for the contents. Collections are done the same way. Sub-collections would be harder with no inheritance of criteria but still possible.
• The “select as default page page” option will be removed
• The root portal object will be like a Page. If editors can have an alias tile. 
• An upgrade step would be created to change the base class of existing p.a.content types objects. Folders would change into pages. Default pages would be merged with their folder. Collections would turned into pages with a single listing tile. In the case where the default page is 3rd party and can’t be made folderish the alias tile will be used. 
• Since the display menu will no longer be used for setting listing templates or default pages so there will be no out of the box display menu options left. It will be kept for backwards compatibility but it doesn’t need to be so prominent We propose moving it into the edit dialog. It would be helpful if it also had a preview mode.
• After removing collections there will need to be a way of creating RSS feeds. We propose a RSS behaviour that adds a RSS query field to content. This will help make RSS more explicit in Plone as it’s currently a hidden feature. Alternatively a separate RSS content type could be created.
• WebDAV will handle adding folders by creating Pages with a single contents listing tile.



Deliverables
----------------

Risks
-------
• Incorporating tiles within tinymce without more use of collective.tinymcetiles poses some risk
• Tiles themselves have been used in production via collective.cover however there could still be some risks involved.
• There might existing other functionality that will be lost hasn’t yet been considered.
• Caching settings have different rules for folderish and content-ish types. You normally don’t want strong caching on automated listing types. Need to work out if we no longer differentiate or perhaps have a way to distinguish content that as a listing tile added.


Dylan Jay

---
www.pretagov.com - Secure SaaS for Government hosted locally.
P: +61-2-9955-2830  +44-87-0392-7071 | linkedin.com/in/djay75





_______________________________________________
UI mailing list
[hidden email]
https://lists.plone.org/mailman/listinfo/plone-ui
c.ledermann c.ledermann
Reply | Threaded
Open this post in threaded view
|

Re: PLIP: Remove default pages

First impression is that option 1 looks better to me, I do not think that a drop down for 3 options is a good UI


On Tue, Dec 31, 2013 at 7:41 AM, Dylan Jay <[hidden email]> wrote:
Hi,

Something specific I'd like feedback on is the change to the UI for sharing.

It currently looks like 
+-----------------+------------+---------------+--------------+---------------+
| Name            |  Can add   |   Can edit    |   Can review |   Can view    |
+-----------------+------------+---------------+--------------+---------------+
| User X          |    [ ]     |     [X]       |     [ ]      |     [ ]       |
+-----------------+------------+---------------+--------------+---------------+

However what we need to do is allow the user to share just the current page without giving sharing anything below it if we are to replace what default pages does.

We could do something like this

+-----------------+------------+---------------+--------------+---------------+
| Name            |  Can add   |   Can edit    |   Can review |   Can view    |
+-----------------+------------+---------------+--------------+---------------+
|                 |here | below| here  | below | here | below | here | below  |
+-----------------+------------+---------------+--------------+---------------+
| User X          | [ ] | [ ]  |  [X]  |  [ ]  | [ ]  |  [ ]  |  [ ] |  [ ]   |
+-----------------+------------+---------------+--------------+---------------+

or maybe with a drop down?

+-----------------+-------------------+------------------+--------------+---------------+
| Name            |  Can add          |   Can edit       |   Can review |   Can view    |
+-----------------+-------------------+--------+---------+----+-------------------------+
| User X          | [ here&below |v|] | [ here       |v|]| [        |v|]| [ below |v|]  |
+-----------------+------------+-------------------------+------------------------------+


Dylan Jay

---
www.pretagov.com - Secure SaaS for Government hosted locally.
P: +61-2-9955-2830  +44-87-0392-7071 | linkedin.com/in/djay75



On 24 Dec 2013, at 4:26 pm, Dylan Jay <[hidden email]> wrote:

Hi Team,

I need your advice. Something to ponder over the holiday period (for those parts of the world where this is a holiday period).
This is the folderish-content types proposal which I've renamed and broken down into three parts:
- Reduce reliance on default pages
- Introduce tiles into the visual editor
- Remove default pages from p.a.contenttypes
The first two can be implemented without breaking backwards compatibility.

I'd like to make it more approachable so the framework team are as enthusiastic as I am about it, and also to get some volunteers to help work on it.
Advice?


https://docs.google.com/a/pretaweb.com/document/d/1jJ7765rW-CpdOhKR6o4hFaOzQk6xmuePFZd-zTzxwFE/edit?pli=1#

Abstract
-----------

Remove the concepts of Folder, collection and default page from Plone, instead all content types will be folderish. This will make Plone easier to use and easier to learn.
This is partial step towards the full deco implementation. It includes replacing collections and folders with a single Page type. Tiles will be introduced however no grid system is introduced and the way content is edited and laid out doesn’t change. How titles, portlets, sharing and content rules are improved to include the “at this level only” functionality.

Motivation
--------------

The motivation is to make Plone more intuitive, require less training for first time users
and to reduce the effort of editing for experienced users. The concepts of default pages and folders are easy to understand if you move from editing static HTML websites but this is increasingly rare. There has general agreement from the UI team about the idea of remove default pages. 
A recent survey (the Plone UX hitlist) showed that the concepts of default pages was one the leading UX hurdles with Plone. 

• #1 for Editors https://trello.com/c/HbWFnggT/26-not-obvious-how-to-edit-publish-folder-when-it-has-a-default-page
• #2 for Editors https://trello.com/c/ryIsWRUm/31-no-out-of-the-box-way-to-include-listings-rich-content-repeated-content-into-the-text-of-a-page (if using folderpagetiles)
• #3 for Editors https://trello.com/c/JYdgXfMK/2-idea-of-default-page-is-not-obvious
https://trello.com/c/7OS5ac9i/24-not-obvious-display-menu-changes-item-no-way-to-preview (if display menu moved into /edit)
https://trello.com/c/lV7a7lEM/56-navigation-being-tied-to-folder-structure-isn-t-obvious

Deco was about improving approachability and making it easier for users to create complex pages. This is a stepping stone towards the original deco idea. We think part of the reason Deco hasn’t yet happened is because its too large a change all at once. It’s both hard to implement and hard for people to accept as an improvement when the step is so large. Hopefully this proposal strikes the right balance of achievability, low risk and user acceptance.



Assumptions
----------------

We assume this change will require a major release. This change introduces backwards incompatibility. Ideally it would be in Plone 5 combined with the p.a.contenttypes upgrade. If it were delayed to Plone 6 we’d either have to wait too long for the usability benefits or we’d have two disruptive releases very close to each other prolonging the pain of upgrades.
It is a disruptive change for the following reasons 
• it changes the data structure of the content types
• breaks third-party plugins using content types
• changes the UX

We assume that it’s not the right time yet to introduce grid based layouts or tile based layouts to replace portlets and viewlets. The motivation for not going all the way to a full deco approach is that deco requires all themes to incorporate a single grid system and it’s not clear what that grid system would be or it’s a good idea for all themes to include a grid system.

The following functionality will be lost. We assume this will be OK.
• have a different workflow for folders and pages
• unpublish a default page while folder is published



Proposal & Implementation
-----------------------------------

This proposal can be broken down into three sub PLIPS. The first two can be implemented without breaking backwards compatibility.

Reduce reliance on default pages
~~~~~~~~~~~~~~~~~~~~~~~~
There are number of features of plone which rely on default pages. The following changes could be made before removing the default pages function. 
• When editing an object, allow for the title and description to be overridden for navigation (side nav, sitemap, top nav, breadcrumbs etc). This might need a new tab.  Could be implemented as a behaviour. 
• Change the manage portlets UI to set a portlet as being either for “this page”, “all pages” or “sub pages only”. This replaces the ability to have two sets of portlets at either the folder level or default page level.
• Change the sharing UI to set a local role as being either for “this page” or “all pages” or “sub pages only”
• Change the content rules assignment UI to set a rule assignment as being either for “this page” or “all pages” or “sub pages only”

Introduce tiles into the visual editor
~~~~~~~~~~~~~~~~~~~~~~~~~
TinyMCE will allow you to insert a tile into a richcontent field such as on a page type. Several out-of-the-box tiles would be supported including content listing (replacing the functionality of collections) and alias (replacing the functionality of using another content object as a default page, if the other content isn’t folderish). TinyMCE will represent the tile with a placeholder such as an image similar to collective.tinymcetiles. Additional styles might need to be introduced to set the width of a tile to 100%, 50% etc.
Optionally introduce a way to use tiles as portlets and viewlets. This will make the development story less confusing as a single way to development these components could be recommended.
An alternative proposal was considered which avoided the use of tiles, instead a combination Page/Collection/Folder type was proposed. Using tiles however has the added advantage that multiple collections can be represented on the same page, and an alias tile can help where 3rd party types aren’t yet folderish.

Remove default pages in p.a.contenttypes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Change plone.app.content types so all types are folderish. 
• The folder type and collection type will be removed and replaced with a single “Page” type. 
• Subpages are created by clicking “add new > page” on an existing page. 
• Automated listing of contents is achieved by inserting a listing tile via tinymce and choosing a query for the contents. Collections are done the same way. Sub-collections would be harder with no inheritance of criteria but still possible.
• The “select as default page page” option will be removed
• The root portal object will be like a Page. If editors can have an alias tile. 
• An upgrade step would be created to change the base class of existing p.a.content types objects. Folders would change into pages. Default pages would be merged with their folder. Collections would turned into pages with a single listing tile. In the case where the default page is 3rd party and can’t be made folderish the alias tile will be used. 
• Since the display menu will no longer be used for setting listing templates or default pages so there will be no out of the box display menu options left. It will be kept for backwards compatibility but it doesn’t need to be so prominent We propose moving it into the edit dialog. It would be helpful if it also had a preview mode.
• After removing collections there will need to be a way of creating RSS feeds. We propose a RSS behaviour that adds a RSS query field to content. This will help make RSS more explicit in Plone as it’s currently a hidden feature. Alternatively a separate RSS content type could be created.
• WebDAV will handle adding folders by creating Pages with a single contents listing tile.



Deliverables
----------------

Risks
-------
• Incorporating tiles within tinymce without more use of collective.tinymcetiles poses some risk
• Tiles themselves have been used in production via collective.cover however there could still be some risks involved.
• There might existing other functionality that will be lost hasn’t yet been considered.
• Caching settings have different rules for folderish and content-ish types. You normally don’t want strong caching on automated listing types. Need to work out if we no longer differentiate or perhaps have a way to distinguish content that as a listing tile added.


Dylan Jay

---
www.pretagov.com - Secure SaaS for Government hosted locally.
P: +61-2-9955-2830  +44-87-0392-7071 | linkedin.com/in/djay75





_______________________________________________
UI mailing list
[hidden email]
https://lists.plone.org/mailman/listinfo/plone-ui




--
Best Regards,

Christian Ledermann

Nairobi - Kenya
Mobile : +254 702978914

<*)))>{

If you save the living environment, the biodiversity that we have left,
you will also automatically save the physical environment, too. But If
you only save the physical environment, you will ultimately lose both.

1) Don’t drive species to extinction

2) Don’t destroy a habitat that species rely on.

3) Don’t change the climate in ways that will result in the above.

}<(((*>

_______________________________________________
UI mailing list
[hidden email]
https://lists.plone.org/mailman/listinfo/plone-ui
David Glick (Plone) David Glick (Plone)
Reply | Threaded
Open this post in threaded view
|

Re: PLIP: Remove default pages

In reply to this post by Dylan Jay
On 12/30/13, 8:41 PM, Dylan Jay wrote:
Hi,

Something specific I'd like feedback on is the change to the UI for sharing.

It currently looks like 
+-----------------+------------+---------------+--------------+---------------+
| Name            |  Can add   |   Can edit    |   Can review |   Can view    |
+-----------------+------------+---------------+--------------+---------------+
| User X          |    [ ]     |     [X]       |     [ ]      |     [ ]       |
+-----------------+------------+---------------+--------------+---------------+

However what we need to do is allow the user to share just the current page without giving sharing anything below it if we are to replace what default pages does.

We could do something like this

+-----------------+------------+---------------+--------------+---------------+
| Name            |  Can add   |   Can edit    |   Can review |   Can view    |
+-----------------+------------+---------------+--------------+---------------+
|                 |here | below| here  | below | here | below | here | below  |
+-----------------+------------+---------------+--------------+---------------+
| User X          | [ ] | [ ]  |  [X]  |  [ ]  | [ ]  |  [ ]  |  [ ] |  [ ]   |
+-----------------+------------+---------------+--------------+---------------+

or maybe with a drop down?

+-----------------+-------------------+------------------+--------------+---------------+
| Name            |  Can add          |   Can edit       |   Can review |   Can view    |
+-----------------+-------------------+--------+---------+----+-------------------------+
| User X          | [ here&below |v|] | [ here       |v|]| [        |v|]| [ below |v|]  |
+-----------------+------------+-------------------------+------------------------------+


These both seem cluttered to me. How about this: First comes a table which is the same as the current one, labeled "Share this item".  Then comes another heading, "Share this item's children." Here is a checkbox, [x] Grant the same access to children of this item.  If the user unchecks the checkbox, a second table appears similar to the first one so they can adjust the permissions for children. This table would default to the permissions from the first table.

How do you actually plan to implement granting one set of permissions to an item but a different set to its children, by the way? From what I recall Zope security gives children a way to control whether or not they acquire a particular permission, but I don't recall a way to control that on the parent, much less provide an alternate set of permissions for children.

David

_______________________________________________
UI mailing list
[hidden email]
https://lists.plone.org/mailman/listinfo/plone-ui
Dylan Jay Dylan Jay
Reply | Threaded
Open this post in threaded view
|

Re: PLIP: Remove default pages


On 4 Jan 2014 04:57, "David Glick (Plone)" <[hidden email]> wrote:
>
> On 12/30/13, 8:41 PM, Dylan Jay wrote:
>>
>> Hi,
>>
>> Something specific I'd like feedback on is the change to the UI for sharing.
>>
>> It currently looks like 
>> +-----------------+------------+---------------+--------------+---------------+
>> | Name            |  Can add   |   Can edit    |   Can review |   Can view    |
>> +-----------------+------------+---------------+--------------+---------------+
>> | User X          |    [ ]     |     [X]       |     [ ]      |     [ ]       |
>> +-----------------+------------+---------------+--------------+---------------+
>>
>> However what we need to do is allow the user to share just the current page without giving sharing anything below it if we are to replace what default pages does.
>>
>> We could do something like this
>>
>> +-----------------+------------+---------------+--------------+---------------+
>> | Name            |  Can add   |   Can edit    |   Can review |   Can view    |
>> +-----------------+------------+---------------+--------------+---------------+
>> |                 |here | below| here  | below | here | below | here | below  |
>> +-----------------+------------+---------------+--------------+---------------+
>> | User X          | [ ] | [ ]  |  [X]  |  [ ]  | [ ]  |  [ ]  |  [ ] |  [ ]   |
>> +-----------------+------------+---------------+--------------+---------------+
>>
>> or maybe with a drop down?
>>
>> +-----------------+-------------------+------------------+--------------+---------------+
>> | Name            |  Can add          |   Can edit       |   Can review |   Can view    |
>> +-----------------+-------------------+--------+---------+----+-------------------------+
>> | User X          | [ here&below |v|] | [ here       |v|]| [        |v|]| [ below |v|]  |
>> +-----------------+------------+-------------------------+------------------------------+
>>
>>
> These both seem cluttered to me. How about this: First comes a table which is the same as the current one, labeled "Share this item".  Then comes another heading, "Share this item's children." Here is a checkbox, [x] Grant the same access to children of this item.  If the user unchecks the checkbox, a second table appears similar to the first one so they can adjust the permissions for children. This table would default to the permissions from the first table.
>

You are right, that would work better by requiring less clicks for the common case. And the less cluttered.

> How do you actually plan to implement granting one set of permissions to an item but a different set to its children, by the way? From what I recall Zope security gives children a way to control whether or not they acquire a particular permission, but I don't recall a way to control that on the parent, much less provide an alternate set of permissions for children.

I'm not sure yet. But in 4.3 you can share the ability to edit a default page without allowing editing sub pages. We need to retain that.
Maybe set a subscriber to always set  sharing on each sub item?
Or maybe get the folderpage to look for special local roles like local_editor?
Or maybe even create a special hidden subitem to store the extra local roles on?
Open to suggestions.

>
> David
>
> _______________________________________________
> UI mailing list
> [hidden email]
> https://lists.plone.org/mailman/listinfo/plone-ui
>


_______________________________________________
UI mailing list
[hidden email]
https://lists.plone.org/mailman/listinfo/plone-ui