Thoughts on the through-the-web editor

[Martin Aspeli]

Hi,

I've been thinking a bit about Plone approachability and the power of
the through-the-web Dexterity type editor. I think we should aim for
it to be at least as complete as the new Diazo theme editor. Moreover,
from that effort we have a lot of the moving parts we'd need to do so.

Here are some things I think we should consider doing:

1) Tidy up the control panel front page. I think it should be a
generic "types" control panel, incorporating the relatively sparse
features of the current "Types" control panel and making it possible
to add/edit Dexterity types.

2) The "Add type" screen could be more user friendly, with better
help text at least.

3) When adding a type, we should immediately go to the edit view of that type.

4) The two "export" actions are great, but it's probably quite hard
to understand what they do. We should make them more user friendly.

5) When editing a type, again it's a bit hard to know what to do (The
"behaviours", for example, is fairly obtruse if you don't know what a
behaviour is). There are also some styling issues that makes the whole
page a bit jumbled.

6) The field editor I think is quite nice, actually, but the
"Settings..." trigger is failing for me right now, with a jQuery error
(Plone 4.3).

7) We need a way to make custom views

I think this is the main sticking point right now for making the TTW
type story useful.

I think we could use the ACE editor (from the new p.a.theming editor)
to make this possible. I think we have a couple of options here:

a) Register a local view multi adapter that invokes some semantics to
render a template
b) Have a behaviour on TTW types that invokes some semantics to
render a template

I prefer option b, I think - local component registrations have a
tendency to get out of sync and are quite opaque.

In terms of templates, again I think we have three options

a) Use a ZopePageTemplate stored in the ZODB somewhere
b) Use Blocks-like HTML snippets with tile declarations to define
field placeholders
c) Use HTML snippets with some other, less generic custom format to
define field placeholders (i.e. data- attributes specifying field
names)

I'm leaning towards option b here too. What do others thing?

In terms of storing this, I think we have three options as well:

a) Store in some persistent ZODB tool
b) Store all templates in a single resource directory (++typeviews++
or something)
c) Store templates for a particular type in a type-specific resource
directory (++typeviews++typename or something)

I'm leaning towards c here.

8) We need a better export/import round tripping story

It should be possible to do two things:

- Export a zip file with one or more types (i.e. so you can
distribute sets) that can be easily imported through the control panel
- Export a zip file with a skeleton Python package containing a type,
for when you want to move to full filesystem distribution

I'd welcome some feedback on the items above. It's probably going to
be what I sprint on in Arnhem. ;)

Cheers,
Martin

[Martin Aspeli]

*think

Thinking about it a bit more, ZPT may be the safer and more flexible option. What I'm thinking, is that when you click "customise view" we generate something that looks like the default view (i.e. lists field labels and values), but in fact is the basic TAL to generate that without any loops, i.e. it has a div for each field with the relevant TAL.

 

In terms of storing this, I think we have three options as well:

 a) Store in some persistent ZODB tool
 b) Store all templates in a single resource directory (++typeviews++
or something)
 c) Store templates for a particular type in a type-specific resource
directory (++typeviews++typename or something)

I'm leaning towards c here.

Another option would be to use portal_view_customizations for this.

[Dylan Jay]

Is this customise the main view or the edit form?
In the TTW plone world diazo will the primary way a new plone user
will templating and arranging html, we could let them use diazo. Even
TAL is familiar to us, it will be something new to them.
An alternative is something like collective.listingviews where you
give them a UI to expose the values they need along with unique css
classes. Then let them use diazo to turn them into the design they want.
What I was thinking would be nice is some form of ttw python code more
similar to a BrowserView than the old pythonmethods. For example, if
there was business logic you'd want to do that in python rather than a
template. One example might be to calculate a an automatic ID for a
content item or perhaps a custom validator.

>
>
> In terms of storing this, I think we have three options as well:
>
> a) Store in some persistent ZODB tool
> b) Store all templates in a single resource directory (++typeviews++
> or something)
> c) Store templates for a particular type in a type-specific resource
> directory (++typeviews++typename or something)
>
> I'm leaning towards c here.
>
> Another option would be to use portal_view_customizations for this.
>
>
> 8) We need a better export/import round tripping story
>
> It should be possible to do two things:
>
> - Export a zip file with one or more types (i.e. so you can
> distribute sets) that can be easily imported through the control panel
> - Export a zip file with a skeleton Python package containing a type,
> for when you want to move to full filesystem distribution
>
> I'd welcome some feedback on the items above. It's probably going to
> be what I sprint on in Arnhem. ;)
>
> Cheers,
> Martin
>
>

> --
> You received this message because you are subscribed to the Google
> Groups "Dexterity development" group.
> To post to this group, send email to dexterity-...@googlegroups.com
> .
> To unsubscribe from this group, send email to dexterity-develo...@googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/group/dexterity-development?hl=en
> .

[Martin Aspeli]

Main view.

 

In the TTW plone world diazo will the primary way a new plone user will templating and arranging html, we could let them use diazo. Even TAL is familiar to us, it will be something new to them.

Correct, although if there are fields people want to expose that are not on the default "boring" view template, then those need TAL to be rendered.

 

An alternative is something like collective.listingviews where you give them a UI to expose the values they need along with unique css classes. Then let them use diazo to turn them into the design they want.

I haven't tried c.listingviews, but I do subscribe to these types of solution.

 

What I was thinking would be nice is some form of ttw python code more similar to a BrowserView than the old pythonmethods. For example, if there was business logic you'd want to do that in python rather than a template. One example might be to calculate a an automatic ID for a content item or perhaps a custom validator.

I'm worried about writing Python through the web, and there are a host of problems with trying to execute TTW python scripts.

I wonder if we can get away with this:

 - you can write ZPT through the web, including to register new ZPT-only views and tiles

 - you can write Diazo rules through the web

 - you can apply tiles and utility views and behaviours written in Python to your themes/views/tiles/types

Martin 

[Dylan Jay]

You not needed to render TAL for that. Listingviews (now misnamed) lets you create "boring" views (not just listing) for any content by just selecting the fields you want or creating a "custom field". The custom field is a single TAL expression that is rendered as HTML (I may switch that to just python). So many easy non boring forms don't require python at all and custom fields are there when you want to make non boring fields. 

There is a worked example of this use case here https://github.com/collective/collective.listingviews/blob/master/README.rst

Is there a use case this would work for?

Perhaps diazocode is longer than a TAL template because current diazo looping is not nice but I think pretty much anything can be done as we expose anything in python the user has access to. 

An alternative is something like collective.listingviews where you give them a UI to expose the values they need along with unique css classes. Then let them use diazo to turn them into the design they want.

I haven't tried c.listingviews, but I do subscribe to these types of solution.

 

What I was thinking would be nice is some form of ttw python code more similar to a BrowserView than the old pythonmethods. For example, if there was business logic you'd want to do that in python rather than a template. One example might be to calculate a an automatic ID for a content item or perhaps a custom validator.

I'm worried about writing Python through the web, and there are a host of problems with trying to execute TTW python scripts.

?

I wonder if we can get away with this:

 - you can write ZPT through the web, including to register new ZPT-only views and tiles

 - you can write Diazo rules through the web

 - you can apply tiles and utility views and behaviours written in Python to your themes/views/tiles/types

Martin 

--

[David Glick (Plone)]

Thanks for your thoughts on how to improve the Dexterity type editor, Martin. They actually are very much in line with my own brainstorming about what needs to happen.  I'm going to respond to specific items below, and also add a few other things I think are important.

On 9/15/12 3:01 PM, Martin Aspeli wrote:

      1) Tidy up the control panel front page. I think it should be a
    generic "types" control panel, incorporating the relatively sparse
    features of the current "Types" control panel and making it possible
    to add/edit Dexterity types.

Yes, I think it should list all the types, whether Dexterity-based or not. Clicking into a type takes you to a 'General' tab that lets you edit the type's title and description as well as configuring where the type can be added (anywhere, within any instance of another type, in specific folders) and by whom, and most of the other settings from the current types control panel.

The workflow stuff should probably get moved to a separate tab which lets you select a workflow like the current Types control panel does, possibly with a graphical representation if Nathan figures out how to make that work. And the ability to jump over to the workflow editor which I assume would be its own control panel.

If you're looking at a Dexterity content type you see Schema and Behaviors tabs. If we add a new Views tab, we can possibly make that work for either Dexterity or Archetypes if we implement it right.

     2) The "Add type" screen could be more user friendly, with better
    help text at least.

Yep.

     3) When adding a type, we should immediately go to the edit view of that type.

Yep.

     4) The two "export" actions are great, but it's probably quite hard
    to understand what they do. We should make them more user friendly.

Yeah. I think we should have one 'export' button which takes you to a separate page that shows you an overview of what is going to be exported, tells you what to do with it, and then has the big export button at the bottom.

     5) When editing a type, again it's a bit hard to know what to do (The
    "behaviours", for example, is fairly obtruse if you don't know what a
    behaviour is). There are also some styling issues that makes the whole
    page a bit jumbled.

The behaviors page definitely needs some work. In addition to an overview of what's going on, we need better descriptions of what behaviors do, and a better way to filter down if you're looking for a particular behavior.

     6) The field editor I think is quite nice, actually, but the
    "Settings..." trigger is failing for me right now, with a jQuery error
    (Plone 4.3).

Probably it's using some selectors without proper quotes around the stuff in square brackets.

One of the biggest things we could do to improve the usability of the field editing is when you're adding a new field, make the field-specific options show up as soon as you choose what type of field you want.

I also want to figure out how to let the user select between widgets for a field, or at least configure attributes of the default widget.

     7) We need a way to make custom views

    I think this is the main sticking point right now for making the TTW
    type story useful.

Yeah, this is the biggest sticking point at the moment, I think. Did you see the mockups I made for this early this year? I also started a branch of plone.app.dexterity to implement it, although I didn't get terribly far.

    I think we could use the ACE editor (from the new p.a.theming editor)
    to make this possible. I think we have a couple of options here:

     a) Register a local view multi adapter that invokes some semantics to
    render a template
     b) Have a behaviour on TTW types that invokes some semantics to
    render a template

    I prefer option b, I think - local component registrations have a
    tendency to get out of sync and are quite opaque.

I'm sort of inclined to go with (a), because five.customerize already handles the tricky bits, and I'm not quite sure how the traversal would work for (a) if you want to have more than one custom view with different names.

    In terms of templates, again I think we have three options

     a) Use a ZopePageTemplate stored in the ZODB somewhere
     b) Use Blocks-like HTML snippets with tile declarations to define
    field placeholders
     c) Use HTML snippets with some other, less generic custom format to
    define field placeholders (i.e. data- attributes specifying field
    names)

    I'm leaning towards option b here too. What do others thing?

*think

Thinking about it a bit more, ZPT may be the safer and more flexible option. What I'm thinking, is that when you click "customise view" we generate something that looks like the default view (i.e. lists field labels and values), but in fact is the basic TAL to generate that without any loops, i.e. it has a div for each field with the relevant TAL.

I think it would be nice to have 2 different things:
1. ZPT, with auto-generation of a basic template with all the fields, like you described. This is good for when the user knows TAL and needs something pretty custom. And this is definitely the one to do first.
2. Something with a more graphical UI that lets you arrange which fields are shown in what order, and whether or not to show their labels, or just the field content. This is inching in the direction of deco, but I think it could still be pretty useful to non-programmer types even if it doesn't allow for full flexibility of positioning and the flexibility of configurable tiles. (As a related aside, if we went with tiles, I'd be a little worried about the performance of rendering the view of a type with a hundred fields.)

 

In terms of storing this, I think we have three options as well:

 a) Store in some persistent ZODB tool
 b) Store all templates in a single resource directory (++typeviews++
or something)
 c) Store templates for a particular type in a type-specific resource
directory (++typeviews++typename or something)

I'm leaning towards c here.

Another option would be to use portal_view_customizations for this.

Let's stop inventing new places for things to be stored. Templates in a folder somewhere is good. :)

 

  8) We need a better export/import round tripping story

It should be possible to do two things:

 - Export a zip file with one or more types (i.e. so you can
distribute sets) that can be easily imported through the control panel

We have the export, but not the import. Can you import if you already have instances of the type?

 - Export a zip file with a skeleton Python package containing a type,
for when you want to move to full filesystem distribution

Yeah, that'd be killer if people didn't have to set up ZopeSkel.

I'd welcome some feedback on the items above. It's probably going to
be what I sprint on in Arnhem. ;)

Some other things:

9) More field types. It'd be fantastic to be able to add a relation to another type, or a data grid with several columns. Even basic things like a URL and an Email field would be useful, especially since we don't have a way to configure validators TTW yet.

10) Configure fields as searchable (both in SearchableText, and with their own indexes -- the latter is a critical step toward building out collections or using addons like eea.facetednavigation).

11) Assign field read/write permissions.

12) Fix schema invalidation - Right now the TTW type editor doesn't work if you're using it on a deployment with multiple instances. That's because there's no invalidation getting sent from the instance where the change was made to tell the other instances that they need to re-sync their dynamic schemas.

13) A TTW builder of metadata schemas that can be assigned to multiple content types. I prototyped this at https://github.com/davisagli/collective.pigeonhole although currently it only adds fields to Archetypes content, because that's what the client needed. (Dylan, this is going to look a lot like collective.facets—which is because I forgot the latter exists until I was already done with the prototype—only it's built around plone.schemaeditor for configuring the schema. Let's talk at the conf about how we can merge our efforts.)

[Martin Aspeli]

Hi,

On 17 September 2012 05:53, David Glick (Plone) <david...@plone.org> wrote:

Thanks for your thoughts on how to improve the Dexterity type editor, Martin. They actually are very much in line with my own brainstorming about what needs to happen.  I'm going to respond to specific items below, and also add a few other things I think are important.

On 9/15/12 3:01 PM, Martin Aspeli wrote:

      1) Tidy up the control panel front page. I think it should be a
    generic "types" control panel, incorporating the relatively sparse
    features of the current "Types" control panel and making it possible
    to add/edit Dexterity types.

Yes, I think it should list all the types, whether Dexterity-based or not. Clicking into a type takes you to a 'General' tab that lets you edit the type's title and description as well as configuring where the type can be added (anywhere, within any instance of another type, in specific folders) and by whom, and most of the other settings from the current types control panel.

+1

 

The workflow stuff should probably get moved to a separate tab which lets you select a workflow like the current Types control panel does, possibly with a graphical representation if Nathan figures out how to make that work. And the ability to jump over to the workflow editor which I assume would be its own control panel.

+1, although workflow without types is meaningless so it may be we need to unify these too eventually.

 

If you're looking at a Dexterity content type you see Schema and Behaviors tabs. If we add a new Views tab, we can possibly make that work for either Dexterity or Archetypes if we implement it right.

+1

 

     2) The "Add type" screen could be more user friendly, with better

    help text at least.

Yep.

     3) When adding a type, we should immediately go to the edit view of that type.

Yep.

     4) The two "export" actions are great, but it's probably quite hard
    to understand what they do. We should make them more user friendly.

Yeah. I think we should have one 'export' button which takes you to a separate page that shows you an overview of what is going to be exported, tells you what to do with it, and then has the big export button at the bottom.

That could work.

 

     5) When editing a type, again it's a bit hard to know what to do (The
    "behaviours", for example, is fairly obtruse if you don't know what a
    behaviour is). There are also some styling issues that makes the whole
    page a bit jumbled.

The behaviors page definitely needs some work. In addition to an overview of what's going on, we need better descriptions of what behaviors do, and a better way to filter down if you're looking for a particular behavior.

Yes, though I suspect it'll be a while until people have so many behaviours we need a lot of filtering.

 

     6) The field editor I think is quite nice, actually, but the
    "Settings..." trigger is failing for me right now, with a jQuery error
    (Plone 4.3).

Probably it's using some selectors without proper quotes around the stuff in square brackets.

I think so. It's looking for "[name=foo.bar.baz]" without quotes.

 

One of the biggest things we could do to improve the usability of the field editing is when you're adding a new field, make the field-specific options show up as soon as you choose what type of field you want.

+1

 

I also want to figure out how to let the user select between widgets for a field, or at least configure attributes of the default widget.

+1

     7) We need a way to make custom views

    I think this is the main sticking point right now for making the TTW
    type story useful.

Yeah, this is the biggest sticking point at the moment, I think. Did you see the mockups I made for this early this year? I also started a branch of plone.app.dexterity to implement it, although I didn't get terribly far.

Probably, but I can't remember now. Where are they again?

 

    I think we could use the ACE editor (from the new p.a.theming editor)
    to make this possible. I think we have a couple of options here:

     a) Register a local view multi adapter that invokes some semantics to
    render a template
     b) Have a behaviour on TTW types that invokes some semantics to
    render a template

    I prefer option b, I think - local component registrations have a
    tendency to get out of sync and are quite opaque.

I'm sort of inclined to go with (a), because five.customerize already handles the tricky bits, and I'm not quite sure how the traversal would work for (a) if you want to have more than one custom view with different names.

You mean for (b) in the second clause there?

I think you're right, although Laurence and I had some discussions yesterday about a plan (c); need to write about that separately once I've thought it through far enough to make sure it isn't entirely crazy.

 

    In terms of templates, again I think we have three options

     a) Use a ZopePageTemplate stored in the ZODB somewhere
     b) Use Blocks-like HTML snippets with tile declarations to define
    field placeholders
     c) Use HTML snippets with some other, less generic custom format to
    define field placeholders (i.e. data- attributes specifying field
    names)

    I'm leaning towards option b here too. What do others thing?

*think

Thinking about it a bit more, ZPT may be the safer and more flexible option. What I'm thinking, is that when you click "customise view" we generate something that looks like the default view (i.e. lists field labels and values), but in fact is the basic TAL to generate that without any loops, i.e. it has a div for each field with the relevant TAL.

I think it would be nice to have 2 different things:
1. ZPT, with auto-generation of a basic template with all the fields, like you described. This is good for when the user knows TAL and needs something pretty custom. And this is definitely the one to do first.
2. Something with a more graphical UI that lets you arrange which fields are shown in what order, and whether or not to show their labels, or just the field content. This is inching in the direction of deco, but I think it could still be pretty useful to non-programmer types even if it doesn't allow for full flexibility of positioning and the flexibility of configurable tiles. (As a related aside, if we went with tiles, I'd be a little worried about the performance of rendering the view of a type with a hundred fields.)

Can we tackle 1 before 2?

 

In terms of storing this, I think we have three options as well:

 a) Store in some persistent ZODB tool
 b) Store all templates in a single resource directory (++typeviews++
or something)
 c) Store templates for a particular type in a type-specific resource
directory (++typeviews++typename or something)

I'm leaning towards c here.

Another option would be to use portal_view_customizations for this.

Let's stop inventing new places for things to be stored. Templates in a folder somewhere is good. :)

Surely, all of the above do that. ;)

If we want to use plone.app.customerize for this, then portal_view_customizations would be the most natural place. I don't know how it would behave if told to register a "customisation" for a view that didn't exist elsewhere (I think this would be fine) and which was identified by a plone.alterego TTW-defined schema (this may be more tricky).

 

 

  8) We need a better export/import round tripping story

It should be possible to do two things:

 - Export a zip file with one or more types (i.e. so you can
distribute sets) that can be easily imported through the control panel

We have the export, but not the import. Can you import if you already have instances of the type?

To update, you mean? I guess so. We'd have to be realistic about migrations, though, i.e. make it clear you may break things.

 

 - Export a zip file with a skeleton Python package containing a type,
for when you want to move to full filesystem distribution

Yeah, that'd be killer if people didn't have to set up ZopeSkel.

I actually thought we could use templer/ZopeSkel internally to generate this, so that we'd remain in sync with "good practice".

 

I'd welcome some feedback on the items above. It's probably going to
be what I sprint on in Arnhem. ;)

Some other things:

9) More field types. It'd be fantastic to be able to add a relation to another type, or a data grid with several columns. Even basic things like a URL and an Email field would be useful, especially since we don't have a way to configure validators TTW yet.

+1

 

10) Configure fields as searchable (both in SearchableText, and with their own indexes -- the latter is a critical step toward building out collections or using addons like eea.facetednavigation).

+1

 

11) Assign field read/write permissions.

+1

 

12) Fix schema invalidation - Right now the TTW type editor doesn't work if you're using it on a deployment with multiple instances. That's because there's no invalidation getting sent from the instance where the change was made to tell the other instances that they need to re-sync their dynamic schemas.

+1 -- to do this, we need to cache it in a _p attribute so the ZEO cache deals with it. We did that in p.a.theming.

 

13) A TTW builder of metadata schemas that can be assigned to multiple content types. I prototyped this at https://github.com/davisagli/collective.pigeonhole although currently it only adds fields to Archetypes content, because that's what the client needed. (Dylan, this is going to look a lot like collective.facets—which is because I forgot the latter exists until I was already done with the prototype—only it's built around plone.schemaeditor for configuring the schema. Let's talk at the conf about how we can merge our efforts.)

Yes, though again probably a version 2 feature.

Martin 

[rik]

i'm coming to these issues from the consuming user end, so i'll characterize what i'd HOPED to find.  also, my thoughts have more to do with features external to zope/plone and their internal implementation.  let me jump in at #8:

On Saturday, September 15, 2012 6:18:11 AM UTC-7, Martin Aspeli wrote:

 8) We need a better export/import round tripping story

It should be possible to do two things:

 - Export a zip file with one or more types (i.e. so you can
distribute sets) that can be easily imported through the control panel
 - Export a zip file with a skeleton Python package containing a type,
for when you want to move to full filesystem distribution

I'd welcome some feedback on the items above. It's probably going to
be what I sprint on in Arnhem. ;)

 
first, i'd expected that the TTW facility would be able to spec some but not all features i'd like in my new types, that a ~zopeskel version would get written into some .../src/new.product directory with all the required profile, etc. directory sub-structure, and with "put your code here" delimiters identifying places i could add the extra bits.  couldn't an improved "Export" button do that sort of meld of zopeskel.dexterity with the current model/template files?

second, i usually begin my design work in UML, using a tool like ArgoUML, and so i was pretty happy with the Archetypes profile that you could use to export AT-style types.  couldn't it be possible to write a new profile for ArgoUML to produce Dexterity types?

[Martin Aspeli]

On 17 September 2012 18:41, rik <rikb...@gmail.com> wrote:

i'm coming to these issues from the consuming user end, so i'll characterize what i'd HOPED to find.  also, my thoughts have more to do with features external to zope/plone and their internal implementation.  let me jump in at #8:

On Saturday, September 15, 2012 6:18:11 AM UTC-7, Martin Aspeli wrote:

 8) We need a better export/import round tripping story

It should be possible to do two things:

 - Export a zip file with one or more types (i.e. so you can
distribute sets) that can be easily imported through the control panel
 - Export a zip file with a skeleton Python package containing a type,
for when you want to move to full filesystem distribution

I'd welcome some feedback on the items above. It's probably going to
be what I sprint on in Arnhem. ;)

 
first, i'd expected that the TTW facility would be able to spec some but not all features i'd like in my new types, that a ~zopeskel version would get written into some .../src/new.product directory with all the required profile, etc. directory sub-structure, and with "put your code here" delimiters identifying places i could add the extra bits.  couldn't an improved "Export" button do that sort of meld of zopeskel.dexterity with the current model/template files?

Yes, I think this would be nice. Not necessarily writing to the filesystem (too dangerous, error prone), but a download you can unzip into src/ yes.

 

second, i usually begin my design work in UML, using a tool like ArgoUML, and so i was pretty happy with the Archetypes profile that you could use to export AT-style types.  couldn't it be possible to write a new profile for ArgoUML to produce Dexterity types?

Yes. In fact, one of the original ideas behind the choice of XML for plone.supermodel was that you could probably do this with XSLT from the XMI that ArgoUML produces to the plone.supermodel XML format.

Martin

[Dylan Jay]

On 17/09/2012, at 5:11 PM, "David Glick (Plone)" <david...@plone.org> wrote:

Thanks for your thoughts on how to improve the Dexterity type editor, Martin. They actually are very much in line with my own brainstorming about what needs to happen.  I'm going to respond to specific items below, and also add a few other things I think are important.

On 9/15/12 3:01 PM, Martin Aspeli wrote:

      1) Tidy up the control panel front page. I think it should be a
    generic "types" control panel, incorporating the relatively sparse
    features of the current "Types" control panel and making it possible
    to add/edit Dexterity types.

Yes, I think it should list all the types, whether Dexterity-based or not. Clicking into a type takes you to a 'General' tab that lets you edit the type's title and description as well as configuring where the type can be added (anywhere, within any instance of another type, in specific folders) and by whom, and most of the other settings from the current types control panel.

The workflow stuff should probably get moved to a separate tab which lets you select a workflow like the current Types control panel does, possibly with a graphical representation if Nathan figures out how to make that work. And the ability to jump over to the workflow editor which I assume would be its own control panel.

If you're looking at a Dexterity content type you see Schema and Behaviors tabs. If we add a new Views tab, we can possibly make that work for either Dexterity or Archetypes if we implement it right.

     2) The "Add type" screen could be more user friendly, with better
    help text at least.

Yep.

     3) When adding a type, we should immediately go to the edit view of that type.

Yep.

     4) The two "export" actions are great, but it's probably quite hard
    to understand what they do. We should make them more user friendly.

Yeah. I think we should have one 'export' button which takes you to a separate page that shows you an overview of what is going to be exported, tells you what to do with it, and then has the big export button at the bottom.

     5) When editing a type, again it's a bit hard to know what to do (The
    "behaviours", for example, is fairly obtruse if you don't know what a
    behaviour is). There are also some styling issues that makes the whole
    page a bit jumbled.

The behaviors page definitely needs some work. In addition to an overview of what's going on, we need better descriptions of what behaviors do, and a better way to filter down if you're looking for a particular behavior.

Even with better descriptions it would still be confusing that both the schema editor and a tick box on behaviors result in fields in the final type. 

Is there are way to make a schema injecting behavior show it's fields in the editor as read only so you can preview the full schema?

I'm still uncomfortable with having more than one way to do something. It's an approach that resulted in Plone being hard to explain and hard to document. 

Each new different way requires more learning burden to understand the limitations of one over the other. 

For example if we are going to present TAL templates to edit a type view why not let the user use templates to modify anything else on the page like other Cms's do. I'm not suggesting we do this just that it would make the system much easier to understand. 

I think we have the opportunity with ttw development to start new. It doesn't have to mirror how we build Plone the application. It also doesn't have to be just a starter to get you into file system development. I think we should be approaching this as a single cohesive UI that will let you build how classes of sites with needing to create a package deploy it. That way ploud becomes easier than Wordpress. 

For example I was looking at requirements the other day for a booking system for interpreters and clients. They wanted it built into a Cms. It has business logic of rounds of offers for jobs and logic about determining pricing. Thinking how we simplify building ttw a concrete example like this might help guide this UI. Documentation driven development approach please. 

I thought you built pigeonhole first and I found out about it later. It would be good to have a core way to new fields without having to create new types :)

[Martin Aspeli]

On 17 September 2012 23:42, Dylan Jay <dj...@pretaweb.com> wrote:

Even with better descriptions it would still be confusing that both the schema editor and a tick box on behaviors result in fields in the final type. 

Is there are way to make a schema injecting behavior show it's fields in the editor as read only so you can preview the full schema?

It already does this.

 

I think it would be nice to have 2 different things:
1. ZPT, with auto-generation of a basic template with all the fields, like you described. This is good for when the user knows TAL and needs something pretty custom. And this is definitely the one to do first.
2. Something with a more graphical UI that lets you arrange which fields are shown in what order, and whether or not to show their labels, or just the field content. This is inching in the direction of deco, but I think it could still be pretty useful to non-programmer types even if it doesn't allow for full flexibility of positioning and the flexibility of configurable tiles. (As a related aside, if we went with tiles, I'd be a little worried about the performance of rendering the view of a type with a hundred fields.)

I'm still uncomfortable with having more than one way to do something. It's an approach that resulted in Plone being hard to explain and hard to document. 

Each new different way requires more learning burden to understand the limitations of one over the other. 

For example if we are going to present TAL templates to edit a type view why not let the user use templates to modify anything else on the page like other Cms's do. I'm not suggesting we do this just that it would make the system much easier to understand. 

I think we have the opportunity with ttw development to start new. It doesn't have to mirror how we build Plone the application. It also doesn't have to be just a starter to get you into file system development. I think we should be approaching this as a single cohesive UI that will let you build how classes of sites with needing to create a package deploy it.

I think there is some merit in this, but we need to a balance it against two risks:

 - People who already know Plone becoming confused

 - The infamous Z-shaped learning of Zope that did for its TTW story, namely that there comes a point when you need to write Python code and access APIs and do developer-y stuff; at this point, you really want to work on the filesystem, with version control, configuration management, and debugging tools. If you have to do things one way on the filesystem and another way TTW, then you have to start from scratch the second your requirements cross over into filesystem territory, which is a terrible experience.

 

That way ploud becomes easier than Wordpress. 

For example I was looking at requirements the other day for a booking system for interpreters and clients. They wanted it built into a Cms. It has business logic of rounds of offers for jobs and logic about determining pricing. Thinking how we simplify building ttw a concrete example like this might help guide this UI. Documentation driven development approach please. 

+1 for trying to drive from a use case centric perspective and writing good docs ;-)

Martin

[David Bain]

Martin,

I like the direction. Making dexterity types more approachable can only be a win.

Dylan,

collective.listingviews works as advertised, justed tested it (also made a minor change to the documentation). I like it. More importantly it is easy to explain to a newbie, with one reservation, the portlet + diazo approach to adding new fields to content items works but is a bit "fiddly" but I can't think of a better approach at the moment.

[Dylan Jay]

On 17/09/2012, at 8:26 PM, david bain <pigeon...@gmail.com> wrote:

>
> Dylan,
> collective.listingviews works as advertised, justed tested it (also made a minor change to the documentation). I like it. More importantly it is easy to explain to a newbie, with one reservation, the portlet + diazo approach to adding new fields to content items works but is a bit "fiddly" but I can't think of a better approach at the moment.

We can enable singleton listingviews on an individual content item. If we did this however then all listingviews would be visible on the display menus on every content type. The alternative is to further complicate the listingview definition to pick which types a listingview is can be added to.