Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC 00012 - New Block Editor (property editor) #12

Merged
merged 11 commits into from Sep 2, 2019

Conversation

@agiraud
Copy link
Contributor

commented May 24, 2019

A final comment period has been applied to this RFC and it will be accepted on 02/09/2019
This RFC has been accepted

A new back-office editor that handles common page structure editing in a simple and intuitive way. The main concept of the editor is to manage list of blocks that represents a web page's structure, where each block is both a collection of content and a way to configure that collection to be rendered. Each content block and configuration is defined by an Element Type to make administrating and editing with the new Block editor consistent.

This editor aims to be an alternative to the popular editors in Umbraco version 7 such as Stacked Content and Nested Content. This editor also aims to be a foundation for other complex editors in the future and it's components will be able to be re-used to develop alternatives to other popular version 7 editors such as The Grid, LeBlender, and Doc Type Grid Editor.

See RFC document here

agiraud added 3 commits May 24, 2019
@protherj

This comment has been minimized.

Copy link

commented May 24, 2019

I really like how Stacked Content works and we have used that successfully as a Grid replacement.

One thing that would be great is if the Blocks could be a bit more like "components" where the configurations and basic rendering markup (js too?) could be bundled together much like a back-office package is today. Basically, it would be more portable and able to be migrated to other projects easier. Perhaps even as part of a package. I realize the markup part is opinionated and not generally part of a package, but if it was a start and easy to override then I think it could work. It could lead to small component libraries or packages that would help get people going faster on building these out.

Another thing that I wish Stacked Content had is a Content Container that could have more that one component in it. I see you are addressing that with a concept of "splitters". However, what if there was a Block type that allows Blocks or multiple components inside of it like a list? Perhaps its simply a component as well, but something built in that could specific what is allowed inside of it and how many of them would be very helpful.

Thanks for submitting this RFC! I'd love to help in any way I can.

@skttl

This comment has been minimized.

Copy link

commented Jun 5, 2019

One thing that makes Grid slightly better than Stacked Content (or Nested Content) is the ability to group "components" into sections. In grid, that could be columns, rows, and layouts.

We use that feature to have section of components who gets more focus in the design, like having a background color, adding some spacing around.

To do that in Nested Content, we would need to have a Nested Content inside Nested Content, and that feels wrong. Also makes it harder for the editor to overview the content, as some of it is hidden inside other content.

@Shazwazza

This comment has been minimized.

Copy link
Member

commented Jun 24, 2019

There's a few questions that come to mind after reading this:

  • To me this seems nearly the same as Nested Content but with some new editor features, being able to apply 'settings' to each element and being able to style the blocks.
  • The RFC is missing information about styling? While at the retreat it was presented that they way this editor would look in the back office would be based on CSS at the developers discretion so that the blocks would flow like they would on the front-end.
  • Are block 'settings' applied per block, or in the data type configuration per element or both? In the section in the RFC under "How to create and set a new block editor" i think the settings part needs some clarification.
  • How do you define a layout block editor? Under "How to handle column and more complex layout" there's mention of columns (or could be rows, etc...) and that you can add something like a "Splitter" block - how is this defined? is it just an empty Element Type and the splitting is determined based on the alias of this type? or what were the thoughts on this?

@agiraud Can this PR be opened up for collaboration (i think that's possible on GH). Would just like to make some grammar and formatting changes for now if possible.

@JasonElkin

This comment has been minimized.

Copy link

commented Jul 3, 2019

In addition to @skttl's comment above, one of the biggest difficulties I have with this kind of editor is with optional properties.

Using the [Title/Content/Image] block from the second image as an example, lets say that this Image is optional, which I find is quite a common scenario.

With Nested Content (I've not used Stacked Content so don't know in that instance) there will always be an image picker. If the editor has chosen not to use an image, then the picker is extra noise/distraction (and payload) in the backoffice.

This also makes for messy views (or view-models, or extra ones entirely) that check for the presence of properties and then make (sometimes quite significant) markup changes, although I appreciate that's probably off-topic at this stage.

We can solve that problem by having a separate [Title/Content] block, but what if the editor wants to add an image later? They need to copy/paste content into a different block.

This is where the Grid currently shines, we only need one [Title/Content] and one [Image]. We also get positioning information which would otherwise need to be encapsulated in settings - e.g. aligning the image left or right of the text - using the grid the editor get's a nice visual representation and we can just render it in order.

@Shazwazza

This comment has been minimized.

Copy link
Member

commented Jul 9, 2019

Hi @JasonElkin , I think with this editor you can also just have one [Title/Content] and one [Image] block to achieve the same thing. I don't see why they couldn't easily be separated into 2 separate blocks and still achieve the desired markup just like the Grid would unless I'm missing something?

@JasonElkin

This comment has been minimized.

Copy link

commented Jul 10, 2019

@Shazwazza yes, that works if the layout is one dimensional - but in this case we'd want [Image] to be next to [Title/Content] and not above or below.

e.g.
[Title/Content][Image]
not
[Title/Content]
[Image]

I guess that's the problem, in making the Image optional I've turned a one-dimensional stack into a two-dimensional grid.

So perhaps this is more an issue with using a 1D stack to edit 2D content. In mobile-first right-to-left websites it's probably not too much of a problem and the "contextual display" will help with that. It's hard to beat the current Grid's "it is where it is" approach.

@hfloyd hfloyd referenced this pull request Jul 10, 2019
@Shazwazza

This comment has been minimized.

Copy link
Member

commented Jul 11, 2019

I 'think' one of the proposals here is that you can insert 'splitter' content blocks to 'break' the flow, so for example you could have a 'column' element type (that might be empty) and you could insert a column after [Title/Content] so you'd end up with: [Title/Content][Column][Image]

That is what is described in this RFC under detailed design under the "How to handle column and more complex layout?"

@nathanwoulfe

This comment has been minimized.

Copy link

commented Jul 11, 2019

Wouldn't that be veering into presentation logic, which the core Proteus editor shouldn't care about? If the editor implementation wants to use splitters or kittens or donuts, cool, go for it - Proteus should allow storing that data, but not care about what that means for rendering. I think.

@nathanwoulfe

This comment has been minimized.

Copy link

commented Jul 11, 2019

Or more succinctly, Proteus should store a JSON blob for the layout property for a given editor. What that JSON represents and how it is used come render time, should be up to the implementation of that editor.

@JasonElkin

This comment has been minimized.

Copy link

commented Jul 12, 2019

@nathanwoulfe I think RFC12 is a proposed Editor, if so it's on topic. And I agree with your sentiments - a separate blob that describes the layout seems preferable to empty 'splitter' content blocks, especially as RFC11 is aiming for interoperability between the blocks/editors. A 'splitter' block that would only make sense in this editor seems to be at odds with that.

Just noticed this exact thing being discussed in RFC11.

@Shazwazza

This comment has been minimized.

Copy link
Member

commented Aug 8, 2019

@nathanwoulfe regarding

Wouldn't that be veering into presentation logic, which the core Proteus editor shouldn't care about? If the editor implementation wants to use splitters or kittens or donuts, cool, go for it - Proteus should allow storing that data, but not care about what that means for rendering. I think.

Yes I definitely agree. I 'think' perhaps what the section on "How to handle column and more complex layout?" might be trying to say is that you 'could' do something like this since it won't prevent you from doing that... but i agree it shouldn't.

I'm working on updating this rfc now and trying to get the POC up and running from the retreat.

@Shazwazza Shazwazza changed the title RFC 00012: Proposed project for Grid Editor based on Proteus Project RFC 00012 - New Block Editor (property editor) Aug 8, 2019

@Shazwazza

This comment has been minimized.

Copy link
Member

commented Aug 8, 2019

Hi all,

I have updated the RFC if you want to read through again (see link in the description of this PR).

@nathanwoulfe after re-wording and undestanding this a little, the notion of 'splitters' and presentation logic is actually 'just' nested block editors, I've updated the RFC to reflect this wording. Of course it would be up to the admin to allow nested block editors but it will be possible.

I'm going to work on getting the POC up and running from the retreat and from there i will prob understand a little more about the implementation details and will make more amends.

@Shazwazza

This comment has been minimized.

Copy link
Member

commented Aug 14, 2019

Hi all, I have made quite a few updates to the RFC if you want to have a read (see link in the description).

@nul800sebastiaan nul800sebastiaan referenced this pull request Aug 19, 2019
@hemraker

This comment has been minimized.

Copy link
Member

commented Aug 19, 2019

Have added final-comment-period for this RFC and it will be accepted on 02/09/2019

@hemraker

This comment has been minimized.

Copy link
Member

commented Sep 2, 2019

Thanks for all the feedback on this one, much appreciated 🙌 Great to see how this has changed from the initial RFC.

Final RFC document can be found here. Will merge this in and we'll let you know once we start POC work and implementation.

@hemraker hemraker merged commit 3b88618 into umbraco:master Sep 2, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.