Re: VIDEO: Simplifying Plone with tiles and shortcodes

On 20 March 2014 23:03, Héctor Velarde <[email protected]> wrote:

> I have to say that I dislike this a lot.
>
> so, to get rid of the "folder problem" we are going to break the metaphors
> behind all of the other content types?
>
> can anybody explain me how can a page contain a page? or how can an image
> contain an image? how do I explain that to a normal user?
>
> if the default view of a folder is difficult to understand (I doubt that),
> imagine explaining a "tile" to a normal user... not to mention that ugly
> and easy-to-break code inside the TinyMCE editor.
>
> sorry, Dylan, but in my view this is a recipe for a complete disaster.
>
> this has nothing to do with enhancing the editing experience in Plone.
>
> we are solving the wrong problems and we are lending bad concepts of
> others CMS to Plone.


I think we should keep separate the "folderish pages" bit and the
"shortcode" bit separate.

I will however share some of the thinking from the discussions around when
Deco was created:

 - The "default page" thing is a slight improvement (from Plone 2.1 - I
know, because it was my first core contribution to Plone) on what we had
before: you could put an object in a folder and give it the id
`index_html`, and then it would act like an `index.html` page did in
Apache. I think that made a certain amount of sense when most users of Zope
were people used to hosting static websites and writing their own HTML, but
it feels quite archaic now. It leads to some very confusing and weird
behaviour, which I think we all have just gotten to used to to question
anymore.

 - The idea isn't to say pages "contain" pages at all. That's just an
implementation detail (and the word "folderish" would need to go away). The
idea is that you look at your nav tree/site map and decide either "I want
this new page next to this page" or "I want this new page in a section
underneath this page". I'm not sure that's such a strange and alien
concept. The shift in mental model is away from thinking about how
file-like things are *stored* towards how the navigation in a website
works. Younger CMSs seem more often to be based on this concept. I think
the original analogy was Google Sites, which was seen as very low
barrier-to-entry thing. When you create a page here, it basically lets you
decide where you want to put it (at the top level, under the page you were
last viewing, or somewhere else using a navtree like thing). I'm not saying
it's the perfect UI implementation (it isn't), but the *concept* is quite
alluring.

 - This is a subtle, but pervasive shift. We'd need to think quite
carefully about how things like the "add" menu worked, for instance,
because that too has a files-in-folder type mentality implied.

 - The idea of Deco was to try to get rid of the need for so many content
types, where you have to choose before you create the content item what
sort of thing it's going to be (and thus making it hard to change it after
you've started). The idea was that an "event", a "news item" or whatever
else are really just web pages with specific layouts and perhaps some
indexable metadata. There were quite detailed UI proposals about how you'd
both select an initial "category" of content (which would imply a layout
and a set of behaviours providing specific indexable metadata) and what
would happen if you wanted to change it later. The upshot of this was that
instead of always creating a whole new type + page template when you wanted
a set of pages with a new, but consistent look and feel, you'd use Deco to
create the first one, save it as a category, and then it would be available
to choose for future items. That's analogous to how "templates" work in MS
Word, for example, but that word is horribly overloaded in our ecosystem,
so we choose not to use it for this too.

 - Files and Images would not be folderish. I don't think anyone's had the
idea that files should be able to contain files. There was a general
consensus that the *default* (but not the only) way to store images would
be a "media repository" type space ("/assets" or whatever) that you'd
upload to from within an "image" tile editor (i.e. you'd either choose an
existing image or upload a new one). The idea was that Plone would ship
with two content types, Page and File, and that Page would have a couple of
categories like Standard Page, News Item, and Event. File would handle both
files and images because, well, images are files and the split is another
archaic Zope thing.

 - One of the things that having explicit folders did, was to make it easy
to get a listing of items ("here are all my articles in date orders";
"these are all our policy manuals as PDFs"). Instead of having a folder
type just for this scenario, the idea was to provide a listing tile that
you could embed in the body of a page (which perhaps also would have some
surrounding text).

What Dylan is proposing here is kind of a "Deco Lite" where instead of any
of the nice drag-and-drop grid stuff, we use TinyMCE wholesale, but still
insert tiles and still converge content types. I do think it only works
once you do it pervasively throughout Plone, though, otherwise it might get
confusing, and you probably still need the "category" concept.

For what it's worth, all of that was built a few years ago as
plone.app.page, which was reasonably feature complete at the time.

Martin

------------------------------------------------------------------------------
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/13534_NeoTech

_______________________________________________
Plone-developers mailing list
Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/plone-developers