RE: [Framework-Team] Re: PLIP 244: Portlet management improvements
-Original Message- From: [EMAIL PROTECTED] [mailto:framework-team- [EMAIL PROTECTED] On Behalf Of Danny Bloemendaal Sent: Friday, October 17, 2008 4:47 AM Cc: framework-team@lists.plone.org Team Subject: Re: [Framework-Team] Re: PLIP 244: Portlet management improvements On 17 okt 2008, at 01:29, Jon Stahl wrote: One other thought to contribute to this topic: Right now, the system renders all placeful portlets, then all group portlets, then all type portlets. Grouping is bad. Especially if you allow some form or ordering. No user wants to be bound by an arbriary technical reason for grouping. If a user wants to have portlets in a mixed order, that is pretty much impossible. Perhaps we can add a simple weight value to each portlet, then order portlets by weight, regardless of whether they are place, group or type portlets? There are some UI considerations, and maybe this is too invasive. But we get it a fair amount. Weight? Why that? Why not allow them to be mixed as the user wants? Why that grouping at all? It's a technical reason not a usability reason. Just allow them to be mixed and you are done. I even would like to suggest to have the option to mix them on a user bases with drag and drop and store the order in cookies or something like that. We have that here in our intranet together with collapsible support and that works really well. But that's another topic ;-). I think control of ordering should (mostly) be a site-admin task, except in the intranet situations you describe where it might be pushed to the user (along with other portlet control). Other than that, I think we're saying the same thing. :Jon ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIP 244: Portlet management improvements
On 17 okt 2008, at 01:29, Jon Stahl wrote: One other thought to contribute to this topic: Right now, the system renders all placeful portlets, then all group portlets, then all type portlets. Grouping is bad. Especially if you allow some form or ordering. No user wants to be bound by an arbriary technical reason for grouping. If a user wants to have portlets in a mixed order, that is pretty much impossible. Perhaps we can add a simple weight value to each portlet, then order portlets by weight, regardless of whether they are place, group or type portlets? There are some UI considerations, and maybe this is too invasive. But we get it a fair amount. Weight? Why that? Why not allow them to be mixed as the user wants? Why that grouping at all? It's a technical reason not a usability reason. Just allow them to be mixed and you are done. I even would like to suggest to have the option to mix them on a user bases with drag and drop and store the order in cookies or something like that. We have that here in our intranet together with collapsible support and that works really well. But that's another topic ;-). Danny. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
RE: [Framework-Team] Re: PLIP 244: Portlet management improvements
-Original Message- From: [EMAIL PROTECTED] [mailto:framework-team- [EMAIL PROTECTED] On Behalf Of Martin Aspeli Sent: Thursday, October 16, 2008 3:39 PM To: framework-team@lists.plone.org Subject: [Framework-Team] Re: PLIP 244: Portlet management improvements Wichert Akkerman wrote: Previously Martin Aspeli wrote: - Create a site wide portlet category for portlets that should show on all pages (unless blocked). Currently, people have to use contextual portlets at the root of the site for this, which gets cumbersome since if you block them in one folder, you need to re-add all portlets in subfolders. This feels like a workaround for the fact that you can not selectively block portlets. I used to think that way, I'm not so sure anymore. Speaking to people about this over the past few months, I've come to realise that our model of thinking that the site root is the parent of all content from which things like portlets can inherit if they need to be site-wide is not how people tend to think about it. I think to most people, the root is the front page and is just a page. You may want some portlets on the front page, or you may want some portlets that are global and show up (almost) everywhere. In our current model, the workaround is that you have to be careful to assign portlets to the root and then not block them unduly. This gets unnatural, especially if you have deep or complex content hierarchies. I would prefer a method where you can both block individual portlets and block only for the current object is, similar to how you propose a flag to only show a portlet in the current object. Right, we need that too. :) One other thought to contribute to this topic: Right now, the system renders all placeful portlets, then all group portlets, then all type portlets. If a user wants to have portlets in a mixed order, that is pretty much impossible. Perhaps we can add a simple weight value to each portlet, then order portlets by weight, regardless of whether they are place, group or type portlets? There are some UI considerations, and maybe this is too invasive. But we get it a fair amount. :jon ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIP 244: Portlet management improvements
On 17.10.2008, at 00:39, Martin Aspeli wrote: I used to think that way, I'm not so sure anymore. Speaking to people about this over the past few months, I've come to realise that our model of thinking that the site root is the parent of all content from which things like portlets can inherit if they need to be site-wide is not how people tend to think about it. I think to most people, the root is the front page and is just a page. You may want some portlets on the front page, or you may want some portlets that are global and show up (almost) everywhere. In our current model, the workaround is that you have to be careful to assign portlets to the root and then not block them unduly. This gets unnatural, especially if you have deep or complex content hierarchies. FWIW i can directly attest to that from an ongoing project. i.e. i have some users feeling pain that would (at least partially) go away if we had this plip already. $0.02, tom ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIP 244: Portlet management improvements
On Thu, Oct 16, 2008 at 3:39 PM, Martin Aspeli [EMAIL PROTECTED] wrote: Wichert Akkerman wrote: Previously Martin Aspeli wrote: - Create a site wide portlet category for portlets that should show on all pages (unless blocked). Currently, people have to use contextual portlets at the root of the site for this, which gets cumbersome since if you block them in one folder, you need to re-add all portlets in subfolders. This feels like a workaround for the fact that you can not selectively block portlets. I used to think that way, I'm not so sure anymore. Speaking to people about this over the past few months, I've come to realise that our model of thinking that the site root is the parent of all content from which things like portlets can inherit if they need to be site-wide is not how people tend to think about it. I think to most people, the root is the front page and is just a page. You may want some portlets on the front page, or you may want some portlets that are global and show up (almost) everywhere. In our current model, the workaround is that you have to be careful to assign portlets to the root and then not block them unduly. This gets unnatural, especially if you have deep or complex content hierarchies. I would prefer a method where you can both block individual portlets and block only for the current object is, similar to how you propose a flag to only show a portlet in the current object. Right, we need that too. :) But since we need it and it effectively solves the same problem, why concentrate effort on the less general solution. Having both will likely give us a few too many ways to do the same thing. Also, +1 on Jon's suggestion for making portlet order independent of portlet assignment type. This is a pretty major shortcoming of the portlet system. Alec ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
