Re: tiles/blocks

On 14 Apr 2014, at 4:34 pm, Guido Stevens <[email protected]> wrote:

> On 14/04/14 07:39, Dylan Jay wrote:
>> On 14 Apr 2014, at 2:59 pm, Guido Stevens <[email protected]>
>> wrote:
>> 
>>> I'm working with Netsight to improve the baseline for Plone
>>> intranets.
>>> 
>>> We've identified having a tile-based layout engine as one of the
>>> key technologies we need to have in place for this.
>>> 
>>> This is not about "full deco" drag-n-drop editable WYSIWIG tiles:
>>> full deco combines both layout (drag-n-drop tiles) and editing
>>> (editable tiles). We want to focus just on the layout aspect and
>>> solve that first. We're interested in rendering a constellation of
>>> application tiles, not multiple richtext fields.
>> 
>> Hi,
>> 
>> It's a bit unclear from the above if you need just the ability to
>> have dynamic "application" functionality inserted into a page, or you
>> need that + some kind of grid system to layout those "tiles" in a
>> layout. You seem to say you want the layout but not a layout editor
>> which I'm not sure makes sense.
> 
> Hi Dylan, thanks for asking.
> 
> I want layout editing without content editing. And I think of layout editing as something that's been done by a development team rather than by a content editor. The goal is indeed to render application tiles into a grid based page layout.
> 
> Currently if I'm doing that I need to hardcode templates that for example place content providers in a Bootstrap3 grid. I'd like to have more runtime fluidity than that and be able to programmatically flow tiles into grid layouts.
> 
>> For example I've been working on tiles without any layout mechanism
>> more than what tinymce already provides.
> 
> Yes, I'm aware of your work, and consider that to be almost orthogonal to what I'm aiming for. AFAICT, you're working on the editing experience (and page model) for folderish richtext content. My priority is not on content, but on rendering of - if you will - portal pages that aggregate tiles from many sources. No TinyMCE in sight.
> 
>> but I'm guessing you do want some kind of layout editor? more like
>> collective.cover?
> 
> I like the part of collective.cover where you define a page grid by drag-n-dropping empty placeholder tiles. But then what you assign into those tiles should be wider than just content or collections, it should be possible to assign arbitrary bizkuwos*. And do that programmatically.
> 
> * any possible term is already overloaded.
> "content providers" "viewlets" "tiles" "blocks" *cough* "portlets"
> 
> And, very important, it should be possible to /constrain/ the space of allowable layout combinations, from a design or management perspective.
> 
>> It might help to discuss the kind of use case that
> 
> As a designer
> I want to define a coherent vocabulary of page layouts and block widgets
> in order to support a consistent user experience.
> 
> As a developer
> I want to dynamically combine multiple information streams
> in order to render a context-sensitive personalized user interface.
> 
> As a user
> I want to select and prioritize information sources and presentation
> in order to maximize my effectivity and minimize information overload.
> 
> Does that clarify?

Getting closer but still confused :)

as you point out one source of confusion is the word 'tiles'. I've been using it to refer to plugin functionality a user can insert into a page, but that includes square shaped html such as inline text such as something that renders the last updated date and time. plone.app.tiles allows for this but the word tile was chosen at a time where deco and grids was how this was going to be implemented... which I'm not sure is certain anymore. Limi's original word is widget which is perhaps better. There might be a better one.
What you seem to want is the widget + grid type idea where the html generated is always in square blocks. is that right?

It's clear the developer creates these widgets. Whats not clear is how you need the relationship between designer/themer, admin of a site and editor of a page to work.
to clarify, I define 
- the Themer to the person who uses diazo and creates some tinymce styles to be used with diazo. This is done normally once in advance.
- the Admin is the person who comes in to set site policies such as deciding what goes on the home page (should that able to be changed by theme. The themer can sometimes constrain them).
- the editor as the person who changes content. Maybe not have access to change all parts of the content including home pages.

It looks to me like you want something that the admin (rather than the themer) to be able to create a layout with some kind of constraints and the layout to be grid based.
Something like a landing page that has certain slots in it in fixed positions where the positions are determined by the admin? Like collective.portletpage except the layout can be rearranged by the admin instead of the themer? Can the editor insert multiple widgets into any slot? Can the admin constrain the set of widget the editor can use?
I think if you can work out what contraints is giving the editing via the layout, that would help.
the collective.tinymcetiles product I was working with assumes the editor has complete control over layout, which doesn't seem to be the problem you have.




> 
> :*CU#
> -- 
>    Guido Stevens  |  +31.43.3618933  |  http://cosent.nl
> 
>    s o c i a l   k n o w l e d g e   t e c h n o l o g y


------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech