[Plone-UI] Folderish Page Proposal

Wed Oct 9 15:19:41 UTC 2013

I'm actually warming up to the original concept anyways--been chatting with
co-workers about it.

The positives really outweigh the potential risks as far as I can see.

You can put me as a +1 on this.

On Wed, Oct 9, 2013 at 9:47 AM, Nathan Van Gheem <nathan at vangheem.us> wrote:

>
>
>
> On Wed, Oct 9, 2013 at 8:50 AM, Dylan Jay <djay at pretaweb.com> wrote:
>
>> On 08/10/2013, at 6:15 PM, Nathan Van Gheem <nathan at vangheem.us> wrote:
>>
>> >
>> >
>> >
>> > On Tue, Oct 8, 2013 at 3:55 PM, Dylan Jay <djay at pretaweb.com> wrote:
>> >> On 08/10/2013, at 4:32 PM, Nathan Van Gheem <nathan at vangheem.us>
>> wrote:
>> >>
>> >> > So starting this discussion back up, I don't like the idea of adding
>> a display tab to the page type and getting rid of the collection type--I
>> thinking solving a problem by creating another less bad problem.
>> >> >
>> >> > However, I really do like the idea of getting rid of default pages
>> and having everything folderish.
>> >> >
>> >> > I'm inclined to say we push plone 5 with the current set of features
>> we've already agreed on and then in plone 6, we move everything folders,
>> get rid of collections and have a deco layout editor.
>> >> >
>> >> > If we just let the deco layout engine be applied to any type, it
>> would also solve the default page issue.
>> >>
>> >> It seems a shame that since we are going to break things with plone5
>> and we seem to mostly agree everything folderish (done right) solves lots
>> of problems, that we don't explore more a stepping stone approach.
>> > I think we need to solve it another way then. I'm not adverse to this
>> but I don't think making a display tab on the page type is a good idea.
>> >
>> >
>> >> I'd like to look more at tinymcetiles since it is more flexible than
>> the page-folder-collection merger but means we don't have to deal with
>> grids in both backend and frontend when we're still not sure how that will
>> work with a world where the frontend could include anything including
>> another grid system.
>> >> Collections get converted to a tile on a page but we don't need to
>> ship with many other tiles. We don't need to change how we do images for
>> example.
>> >> We also don't need to change portlets yet or include the deco idea of
>> saved layouts.
>> >> When you think about it, its almost the same as the proposal to merge
>> collections and display into the page type, except that you can pick where
>> in the page that listing goes, instead of it being at the bottom.
>>
>> > Okay, I'm intrigued with this also.
>> >
>> > Some thoughts:
>> > - would we still keep the collection type around for plone 5?
>>
>> Rob's proposal came out of the us thinking "if you get rid of default
>> pages, then you can't have collections as default views, whats the best way
>> to support collections?".
>> It's possible we could keep collections and make them folderish but
>> accepting all other types. This would make things that want to be views on
>> top of collections easier to upgrade.  Or Rob's proposal is basically the
>> same thing except page==collection. We could do that in addition to
>> supporting tiles but possibly make it confusing as there would be two ways
>> to make a "collection".
>>
> Right. I understand that. I was just carrying on the idea of tinymcetiles
> which I thought we'd only pursue if we didn't merge the collection with
> page.
>
>
>>
>>
>> > - still make everything folderish and get rid of default pages
>> > - do we need to add a rich text field to the Folder type?
>>
>> No, I think folder and page merge. Although again we could keep it to be
>> safe and for backwards compatibilty but I think it would be confusing.
>>
>>
>> > dealing with migrating a site that uses all kinds of folders with
>> default pages could be really messy
>>
>> a little messy. I think all default page items will have their base class
>> changed to be a folder. then they will be move to where their parent folder
>> was and the contents moved into them. Also all items have to have two tiles
>> and descriptions so the folder tile and description are not lost and still
>> appear in navigation.
>> I think its doable but how to upgrade third-party content types is the
>> hard part I think.
>>
>> > - maybe just use js patterns instead of tiles? Or is that a bad idea to
>> mix the concepts?
>>
>> I think that would be a bad idea since it means lots of ajax loads per
>> page and requiring JS on the frontend.
>> Tiles are kind of like patterns but on the server side I believe. They
>> have two ways to store their configuration. Either as http arguments or in
>> annotations. The idea of storing their data in html5 data attributes is
>> interesting however to make them closer to patterns. But for now I think
>> there is no need to change it. Tiles are implemented and working in places
>> like collective.cover. All we are talking about here is to insert them via
>> tinymce and then have the extra rendering step that converts them to full
>> html.
>> One issue is perhaps that the layout options in tinymce are limited. In
>> tinymce you can left and right float and put them in invisible tables but
>> not much more.
>>
>> >     - The TinyMCE integration would just provide a form to insert the
>> appropriate pattern markup
>> >
>> >
>> > Although thinking about it more you still don't get rid of the display
>> menu completely as what happens to plugins like solgema.calendar? They rely
>> on being views on collections. I guess they would have to turn into a tile
>> instead and include the query in their own configuration?
>> > We're not getting rid of the display menu. We're just trying to get rid
>> of the default page selection
>> >
>> >
>> >
>> >
>> http://svn.plone.org/svn/collective/collective.tinymcetiles/trunk/README.txt
>> >
>> >
>> >
>> > >
>> > >
>> > > -Nathan
>> > >
>> > >
>> > > On Sun, Oct 6, 2013 at 2:48 PM, Nathan Van Gheem <nathan at vangheem.us>
>> wrote:
>> > >
>> > >
>> > >
>> > > On Sun, Oct 6, 2013 at 2:43 PM, Johannes Raggam <raggam-nl at adm.at>
>> wrote:
>> > > I like the idea to have everything folderish and to get rid of the
>> > > "Default View" mechanism.
>> > >
>> > > For my projects I always use folderish types because I see a lot of
>> > > advantages in it. For Archetypes based sites I use
>> > > collective.folderishtypes.
>> > >
>> > > In my experience, this has these usability downsides:
>> > >
>> > > - The folderish types don't show their contents in their view (I
>> solved
>> > > that with a viewlet or portlet on folderish types).
>> > > Make the new folder contents much more useful and encouraging people
>> to use it more should should help this.
>> > >
>> > >
>> > > - After adding a folderish type, one lands in it's detail view and
>> > > immediately adding another item adds it into the content created
>> before.
>> > > That's not what you'd expect if you're in a hurry and doing lot's of
>> > > editing. (Can be solved by redirection after creation to the parent
>> > > folder)
>> > > Everyone should take a look at the new folder contents in the mockup
>> project. There is an add menu there that creates the content while keeping
>> you in the folder contents view for these types of situations where you
>> want to add a lot of content at once to build your site quickly.
>> > >
>> > >
>> > > Like Martin, I dislike mixing the Collection functionality into a
>> > > Über-Page. To clients I always explain the Collection type as
>> something
>> > > as a Search-Folder and I - from a user-perspective - wouldn't expect
>> > > that functionality in a "Display" fieldset. A collection can still be
>> > > folderish too.
>> > >
>> > > I'm unsure on getting rid of the "Display" menu. While moving it into
>> > > the editing fieldsets could be a chance to allow users to also add an
>> > > optional content listing of their folderish content, the current menu
>> > > placement makes a lot of sense to me.
>> > >
>> > >
>> > >
>> > > Johannes
>> > >
>> > >
>> > >
>> > >
>> > > --
>> > > programmatic  web development
>> > > di(fh) johannes raggam / thet
>> > > python plone zope development
>> > > mail: office at programmatic.pro
>> > > web:  http://programmatic.pro
>> > >       http://bluedynamics.com
>> > >
>> > > _______________________________________________
>> > > UI mailing list
>> > > UI at lists.plone.org
>> > > https://lists.plone.org/mailman/listinfo/plone-ui
>> > >
>> > >
>> > >
>> > >
>> > > --
>> > > Nathan Van Gheem
>> > > Solutions Architect
>> > > Wildcard Corp
>> > >
>> > >
>> > >
>> > > --
>> > > Nathan Van Gheem
>> > > Solutions Architect
>> > > Wildcard Corp
>> > > _______________________________________________
>> > > UI mailing list
>> > > UI at lists.plone.org
>> > > https://lists.plone.org/mailman/listinfo/plone-ui
>> >
>> >
>> >
>> >
>> > --
>> > Nathan Van Gheem
>> > Solutions Architect
>> > Wildcard Corp
>>
>>
>
>
> --
> Nathan Van Gheem
> Solutions Architect
> Wildcard Corp
>

-- 
Nathan Van Gheem
Solutions Architect
Wildcard Corp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.plone.org/pipermail/plone-ui/attachments/20131009/ec54e4ed/attachment.html>