The main reason we still use grid (in combination with DocTypeGrideditor), instead of the Blocklist editor, is that inserting text via the RTE and Heading editors is fast and intuitive for content managers. Is the pland to retain this functionality (inline editing)?

Great work on this one! There is a lot of things I like, that I would have never thought I wanted (like the row span-thing). One thing that I think is important that is not explicitly stated here is some kind of “re order mode”. The current solution for the Grid (where the edit mode shows a very small representation of the “block”) is a lot easier than the block editor when you want to move content between rows/columns. This is just one thing that came to mind - might think of more but this sounds great! H5YR

Hello @nielslyngsoe - I would like to pitch in on this and share my experience on creating a Grid based on the Block List Editor!

Introduction

When Umbraco 9 went live last year, I was at a crossroads from a technology perspective.

I absolutelty love the grid and we based a lot of technology around it over the last few years. You can get an idea by looking at our Umbraco Awards 2019 showcase: https://youtu.be/AcNSRWttC58?t=22 - and it has been extended upon quite a lot since.

However, we started developing this before the Block List Editor and Nested Elements were a native thing in Umbraco, and it has been pretty clear from the amount of love these things were recieving that the Grid was going to be deprecated at some point, in favor of the Block List Editor.

So with the release of v9, I reallly wanted to start clean and base our grid technology on the Block List Editor instead. At the time of the Block List data model RFCs, there was a lot of talk about making it flexible enough so it could also facilitate grid-based layouts, both in terms of views and data structure. So I was convinced that I could easily add something like that. Needless to say, I was disappointed to find out it actually wasn't...

The good

So let's start with the good thing about the Block List Editor: It's static typed due to Element types and ModelsBuilder. We built our own static typed version of the Grid so we could easily add new grid components based on Document Types. So it was an absolute win the Block List Editor offered this out of the box: we didn't have to maintain this portion of the code anymore, hurray!

The other good thing was the slick UX for adding new blocks for both the developer and the content editor. While I was really accustomed to our little grid component popup, the overlay just felt so much more integrated with Umbraco, so another win!

Also being able to decide when to render a block in the backoffice as inline or in an overlay was something we had built for the grid.

In short, a lot of positive boxes were being ticked, paving the way of moving our work done on the Grid to the Block List Editor.

The bad

But then, dark clouds started forming... One of the core features of our Grid was the ability for the content editor to create a row layout on-demand. We would predefine certain sets of common used row-layouts (eg. 3-3-3-3, 8-4, 12, etc)*. But if they needed something like a 4-8-2-2, they could just define it on the fly and add it to the grid.

* By the way, we always used a single container-layout with a width of 12 columns, so the grid would skip that step and immediately let someone add rows to a page.

So I started investigating how to add a grid data model to the Block List Editor. Unfortunately I came to the conclusion it just wasn't possible to approach the above functionality. Even worse, I couldn't even find a proper way to add the concept of columns... At least, not in a statisfying way.

I say statifying for a reason: One of my core targets while building the reimagination of the Grid editor, was to use as much native [to Umbraco] functionality as possible. Our version of the grid was highly customized at this point. It was starting to become a bit of a Frankenstein, mixing native and custom code, making it very hard to maintain. If Umbraco changed something on their side of the code, we would have to go over the changes and make sure they still played nice with ours. So I was dead set on using only native functionality.

With that in mind, let me share some of the many implementations I tried without resorting to replacing native code.

A block per row

After a few tries and iterations, I settled with the idea of having a Block List Editor datatype that would contain Row-blocks. These Row-blocks would then have a property for each column in the row. The datatype behind this property was another Block List Editor that would contain Component-blocks like a Header, RTE, etc.

By then adding a custom view to the Row-blocks, I could use some basic CSS to represent a grid-row.

Eventually I took this to the next level and created a single custom view HTML to be used on the Row-blocks, and then decided how to render the columns based on a naming convention. eg. If I would add 3 properties with the names column-1-4, column-2-6, column-3-2, the view would know it had to render 3 columns, and the appropriate CSS classes would be applied to show them in the right proportion.

From a code perspective, I then added an extension method for the generated Row-models, so I could get the "Components" of a particular column on a particular row.

It worked pretty well, but I really didn't want to define a row configuration in this way. It also didn't solve my problem of custom row configurations on-demand. On top of that, moving blocks from one column to the other was a hassle and you had to use the copy/paste functionality for that.

One row to rule them all

I started playing with a few different ideas. How could I have the cake and eat it too in terms of not replacing native code, not adding a new document type for each row configuration and still allow on-demand creation of row configurations?

After a lot of fiddling, I came with the following solution: Create Row-block with a property that was a Block List Editor datatype, that could contain Component-blocks. Then add another property with a textstring, with the intention of containing metadata about the column structure*. By mixing this with a custom view for the Row-block and a sprinkle of AngularJS magic, we were able to define block elements on the fly. Better yet, we did this without having to replace any of the existing native code! We only added to it.

* Metadata would describe the row definition as well as which Component in the Block List Editor property belonged to which column.

The ugly

You might wonder why I didn't use a Settings document type to contain the metadata, instead of a textstring property. And that's where the first cracks in the solution start to appear: the data of the settings overlay doesn't actually load until you open the settings. You therefor can't access the data on how to render the row-block when you need it...

Then I decided to use a custom layout instead to store my metadata. However, this meant that I had to implement all logic of the default layout code again, meaning I would recreate a similar situation as with my Frankenstein Grid. My wish here is that I can add my own layout structure, reusing the existing implementation, but only adding to it. But for now, this was absolutely a no-go.

Another issue with this is with dragging/dropping components from one column to the other. Within the same row that works, if you ignore my "no replacing native code"-rule and modify the ng-sortable settings to do so. However, allowing cross-row dragging/dropping will result in losing components if you move them from row to row like this.

There were also issues with copy/pasting rows. After a lot of debugging, this was caused by the PropertyResolver implementations making certain assumptions about the block data structures and actually stripping out UDI's when making a copy. I had to again break my rule and make a very ugly hack to prevent/circumvent this.

Last but not least: it's very apparant it was attempted to make the Block List Editor JavaScript code extendable, by adding things like model factories and services. But in the end, this didn't actually help in solving any of the above issues and things are actually still suprisingly closed. I still had to hack around quite a lot to get the Block List Editor to things I wanted it to do.

I cannot fully recall all the things I ran into in all of my prototypes, but one of the pieces of code I had to copy to be able to use it was the mapToElementModel and mapToPropertyModel functions. I needed this so I could properly add a Document Type based column-settings overlay and store it using the same logic as the Settings overlay.

Conclusion

All in all, we made it work one way or another and have been using this solution in 3+ production websites already since the start of this year. On top of that, because we used a similar structure on how to define the Block components (as we call them now) compared to our Grid components, pretty much all our Grid components also work in the Block List Editor.

We now have a far more superior and future-proof version of our good ol' grid and the with a handful of managable hacks aside, I'm pretty happy with it.

Wishes

What I would like to see as part of this pre-RFC is that the code gets a some love in terms of extension points. It should be possible to sit in between certain implementations and extend/re-use them, rather than being forced to replace or hack around them.

From a functionality perspective:

• Custom view for a block, but while still allowing opening an overlay with its properties. Not just one or the other.
• Predefined row-configurations and on-demand row-configurations (when allowed by the datatype, obviously).
• Row-settings, Column-settings and Component-settings. Settings should be loaded and available immediately when a custom view is used, so the data in those settings can be used to control the rendering of the custom view in the backoffice.

Last but not least, I would really like to see that the implementation of the RFC uses the "layout" system and re-use as much of the existing code as possible. This way, the layout system will naturally get a lot easier to extend to your own tastes, without having to copy large portions of native code.

Demo

For everyone's entertainment, a quick run through our implementation:

Just for the record: after Saving I do a hard page refresh to demonstrate that things are properly persisted. Obviously, a content editor can just continue working without having to do this :)

I thinks there is some great highlight so far.
Something we missed in the old Grid editor was the ability to know about the context (row and column configuration). E.g. if an image block is placed inside a tiny column or full width.

This can be set to any number, the default will be 12 columns.

I think we can assume the lowest number should be 1 and maybe a upper limit? I know the current Grid editor has some UI issues, when configurating a high number of columns in a row, e.g. 50

Some challenges I have had with the old grid editor was that if confugiuration a layout with 10 columns using e.g. Bootstrap, the Grid editor didn't support to make a column at size 25% (10 / 100 * 25 = 2,5 column). However you could still archieve this in frontend using 25% width althouh older versions of Bootstrap didn't support this using the column classes. In newer versions of Bootstrap (and other frameworks like Tailwind) this is much easier to archieve using dynamic column classes.

What I would like to see with a Grid Editor is a way for the editor to preview the Small / Medium / Large / Extra Large layouts and potentially add different settings for each level. You don't always want content to simply become a single column when viewed on mobile and it would be great if the content editor was able to configure this.

Or, if developers were able to pre-define layouts for all four levels, so if you added a specific layout for the normal desktop view, it would automatically have pre-defined layouts for each other level. Having the ability for the editors to be able to view this in the back office would be great.

I hope the above makes sense :)

Will the new implementation still support the settings/styles configuration on the rows, cells and controls? I use these a lot in my umbraco builds to modify how the grid pieces render, mostly to control spacing between the various elements in the grid.

Also, it would be helpful to be able to nest settings under an alias instead of having to set up a convention in the grid partial that groups them. For example, I currently use the following aliases

• class-1 - has value "small-spacing-bottom-1"
• class-2 - has value "medium-spacing-bottom-2"
• class-3 - has value "large-spacing-bottom-3"

The view looks for this pattern and concatenates them all under the "class" attribute so that it can output something like

<div class="small-spacing-bottom-1 medium-spacing-bottom-2 large-spacing-bottom-3">
    ...
</div>

Ideally, the configuration would support the following structure

• class
  • 0 - has value "small-spacing-bottom-1"
  • 1 - has value "medium-spacing-bottom-2"
  • 2 - has value "large-spacing-bottom-3"

This would allow the view to just join the values instead of relying on a convention to identify what properties to include in the attribute. This also makes adding new properties easier, as I wouldn't have to look through the configuration to make sure I wasn't using an alias.

The styles configuration would behave the same way, except the aliases correspond to css properties output via inline styles instead of node attributes.

This should be a behavior that can be toggled on somehow for particular aliases, as not all properties would necessarily function this way.

Another change I would like to see involves how controls are restricted to specific blocks. In the current grid, the allowed controls are set by selecting an area and choosing the controls that are allowed inside it. This works, but is cumbersome when need to add a new control to multiple layouts, as I have to open each layout, choose each area I want the control in and then add the control to it. It would be nice to have a section that reverses how this is controlled, so that the developer can select a control and then choose the areas that control is allowed in. The layouts could be displayed all at once with their areas inside, and the user could just click the areas to enable/remove the control from the area.

Adding to the previous comments we often have the situation where we need to enable & disable blocks, I would hope that this could be built in as a property. Having built a few sites where editors are creating quite complicated layouts I would like the 'Save & Preview' functionality to be extended so you can preview the page and still have control to move / re-arrange the blocks. The block editor is quite simple if you have less than 10 blocks, but many previous sites we've built can contain 50 blocks per page. This is why I think having the ability to re-arrange blocks in the page preview I think would possibly help with this experience for editors.

Another thing that would be nice is to be able to add new blocks anywhere within the grid instead of just at the end. Some pages I worked with have many rows of content in the grid, which makes adding new rows near the top annoying as I have to scroll down to the bottom of the grid and then drag that new row back up to the top.

Hiya

So having read through some of the issues and comments raised so far - I wanted to share with you our implementation of the grid and where I think improvements could or should be made, things that are less important and things that are critical for keeping or having some sort of equivalent.

Within our overall website I have given the editors the ability to create 'mini-sites'. These are routed through the same master controller so are technically all part of the same site (as opposed to a multi-site solution) but then are routed to use an independent set of doctypes and templates that are not connected to the main site.

The objective was to give some of our editors total freedoms to create their own layouts with distinctive brand identity without the trappings or restrictions imposed by the standard templates and doctypes of the main website that is designed to be much stricter in terms of what editors can and cannot do.

As such - the grid was the perfect mechanism for allowing editors to create custom layouts - further, in combination with the doctypegrideditor, we could easily create custom widgets that enable editors to do all sorts of things, such as integrating with libraries such as HighCharts for example.

You can see how we translate the grid layouts to the final site in the examples below:

The key thing is the ability to style each row and cell by using the style and settings json that comes with the current grid editor. I've had to do some tweaking of this along with a bit of angular to make things like colour pickers to work:

This is one of the areas I feel can be greatly improved. I could see from previous comments that you've given it some thought - however it may be counter-productive to either make it more complex, or to not resolve the current issues.

The main problem I've generally had is generally the same that exist with the doctype grideditor - namely that the returned data is in .json so in order for things like colour pickers to work directly then they need an equivalent converter in order to be able to return the colour value in the correct syntax. There are similar problems with things like custom classes within the styles json that I've had to create 'workarounds' - but ideally this could all be improved greatly without needing to be so fiddly.

The thing for me though - is having the ability to customise each cell both outer and inner - and from what I've been reading, if you can have cells within cells within cells then it definitely opens up some possibilities - but you don't seem to be sold on the ability to customise everything - yet this for me is the key power behind the grid - it's not just the ability to provide custom layouts - but that the individual elements of each grid layout can be styled either collectively such as across a row - or individually such as a cell / column.

One of the things of concern after reading the proposals - is that you plan to move away from a 12 column layout as per the current implementation. I'm certainly not wed to the bootstrap way of things (although must confess to being a fan of bootstrap) - but at the same time I really am not sure about how your proposal will work for the editor and wether or not it is too much freedom. The point here is that with the 12 column approach - it means I can easily design my CSS classes so that everything fits together in a continuous way - in other words I know where I am and what I'm doing because everything is designed to 'fit'. That said - you could easily come back to me and say I just need to design my components better to make them more modular / BEM - so I've gone and argued myself into a corner ROFL

Another area is of how the previewed grid in the backoffice will work. It really needs more in the way of the backoffice CSS in order to provide more feedback information to the user - such as focus styles and borders on elements to give the editors information about which grid element they have selected and so on. Although to be fair - the 'preview' function I am using is via the DocTypeGrid editor. But then I would think much of what you hope to achieve is to replace the DTGE

Anyway - I really hope that gives you some insight and ideas. I've ran out of time and probably have more to say on the issue so will have a further think and come back to this thread later on. Hope this is helpful

@nielslyngsoe I've been playing around with the Block Grid Editor-branch during CodeCabin and tested it out in it's current state.

I'm not sure if you're at a stage where you would like to have input or if this is the right channel?

My main concern at the moment is that almost everyone who got involved in this discussion shows a clear need to be able to work with "rows/columns"-based layouts. The current state of the editor makes this possible but it really feels like the big efforts have been put into making it a "CSS-grid" layout builder. This is a really nice and cool use case but I also feel the need to rise the fact that many people will most likely use the Blocks with Areas to "replicate" the row/col setup and I think that this is something that you need to keep in mind and do some testing around as well. Might also consider to make it possible to disable "block the col-resize" if this is not used and the "forece right left"-feature.

I also noticed that the current drag and drop does not allow dragging items from an area to another (guessing that this is on the roadmap) but this is an important thing. It also important to make the sorting in general easier - this is especially important when you have a custom view that takes up a lot of place - a sortmode where only the headlines are visible (or something) would be very helpful in these scenarios.

I would love to contribute with testing and feedback going further - please let me know if this is wanted and in which channels the feedback should be shared.

@nielslyngsoe I was at the same CODECABIN event as @enkelmedia when this was showcased. I agree with the sentiments and considerations raised by them, and the others raised at the event.

I sadly wasn't aware about this feature or the RFC so sorry for delayed feedback. The effort and work that has gone into this looks great, in particular the configuration side for admin/developer roles. I really liked the ability to specify how a block can be used, rather than what blocks can be used in a column.

However, based on the event discussion, my experience in UI/UX, and seeing how our editors use Umbraco at the moment (the grid in particular), I worry and very much anticpate editors will find the editor user interface (during creation) far too complex/technical to use correctly.

The current grid was really good at suggesting a visual outcome. The ability to quickly add rows/columns before choosing the content also let editors plan the layout ahead of time. While we encourage content-first for our editors, this is not always possible and is often left as placeholders until the content is available.

In the example we saw, it seems very difficult to plan ahead during the content adding process. It was also very difficult to visualise how this would become a "grid" at the end. Perhaps its the block-first approach that could cause most confusion? Imagine an example: you would not expect an editor to add the content to a table cell until the table, rows and other cells have been created first.

The current grid can work really well (if used modestly and with certain restrictions), and the editor doesn't need to know technically how to add a row/column, or anything about flex or CSS grid.

In my case, this will lead to:

• Not upgrading to the Umbraco version that only supports this block grid option
• Implement an inferior approach that has no visual guidance (this could negatively represent Umbraco as an editor experience)
• Creating a custom grid editor more like the current implementation (or use another package that is similar)

Like @enkelmedia, please let me know if I can provide any other feedback or contribute to making this a great editor experience.

Just took a quick testdrive, I like what it shows so far!

One tiny thing I would love, if it you could make a block disallowed at root.

In example, I created a block grid with a row block defining some areas for blocks to be added to, a card block, and a picture block.

I don't want the editor to create rows inside of rows, but I can only do that by specifying every single allowed block type in each area. That can be quite cumbersome. Can we have something like "Allowed in areas" like we have Allowed in root?

Another thing, that might just be a WIP bug, when I add one block to an area, I can't add more blocks to the same area afterwards. I have set the area to contain 0 to infinite blocks.

I just tried Umbraco 10.3 and the Block Grid Editor looks great! The only thing I'm still missing, but maybe that will come, is that the demo blocks for Headline and RTE lack the inline editing that the current Grid Layout has. Will that still be part of the final version or is that outside the scope?

Hi everyone

Sorry to jump into this chat so late on but I thought it might be helpful to get involved.

There was a comment above that sums up my general concerns of a tool like this; "enables you to make something that looks like your website". The word "something" suggests that it probably won't look exactly like your website, and how could it, since this is within the back office. With a tool like this, it either has to look exactly like your website or it has no point in being there.

Umbraco needs to make a decision on what the content section is for, is it:

A) An area to create, add, edit and remove content.
B) A web design tool.

Personally, I would suggest that it is A, and it should continue to be that. Now, that's not to say that Umbraco can not introduce tools like this, far from it. You only need to look at the interface on a tool like StoryBlok, TinaCMS, CraftCMS and more to see that there is a way to marry a design tool and a content editor tool together.

For instance, within the above CMS, they typically offer a visual editor POV as well as the traditional form editor (text inputs etc) POV.

Within the visual editor POV the user can see an exact visual representation of their website — great. They can even view the visual representation at a variety of different screen sizes and typically this is through a sort of "preview mode" of the site. However, even within these visual editors the user is never dragging/dropping/expanding elements within the visual, they are still controlling the order, structure, settings from a small slide out panel. Settings such as deciding the width of a section or where it sits within the page should be made in the slide out panel, not on the user interface — otherwise, you are hoping that your content editor is a web designer.

If a user returns to the back office area, they can edit the traditional way using form fields etc.

So far, from what I've seen of the new Block Grid Editor, is that it is a web designer interface inside the content area of the back office. Where a content editor needs to drag/drop, expand column widths etc to try and create a sort of visual representation of their frontend website. From my own experience of working with content editors, this is going to create a major blocker for them to create, edit, and publish content and I don't think I would be in a minority with that view.

Now, I do think the effort and work that has gone into this new editor is impressive and hats off to those involved. However, I don't think it is the correct area of the back office nor is it helpful to your average content editor. It would probably be better as a separate layer to the back office, for instance, a "designer" section. This would then allow a UI designer to use the drag/drop/expand tools to create Content Templates that would be available to users in the Content section. Rather than having a content editor make too many complex design decisions.

Personally, I would like to see Umbraco invest time in bringing an editor experience into the preview area, rather than try to build Webflow inside the back office Content section. For instance, if a user has permissions and the correct markup is in the code, then when a user opens preview there is a slide out panel that can access the docuement type settings and Block List Editor. The content editor can then edit content in the slide out panel and see the exact results on their website preview.

Below is a small (very rough) mockup of the sort of design tools I believe would improve the editor experience and reduce developer headaches during training and offering ongoing support.

I do hope my input is useful and like I said above, the work on this has been awesome so well done, but I'm just concerned how this helps the content editor.

Thanks!

Hi,

Great work on the block grid editor !!!!

I've just tried it and may be missing something - didn't know the correct place to add my comment so I've created it in the issues list ( #13154).

Thanks
Andy

Hi @nielslyngsoe and everone!

We've had a very interesting day giving the 10.3 RC block-grid version a go today.
First of all I'm impressed by the apparent simplicity of the front-end code. H5YR!
It must have taken forever to get so small, elegant and "right". 😄👍
Not to mention how fast this came around to something tangible.

Here's our first impressions and some wishes/feedback:

First impression:

Coming from a long-time grid user perspective without ever using the block list editor
it was quite the challenge to offload the layout, row and cell mentality.
What on earth is this block and groups concept?
What does this colspan stuff apply to? (And how on earth do you set them per "row"?)
We started making a row element type and set the column spans there, but ofc. that didn't work.
After an hour or two it started to dawn on the four of us how this was all structured.
I think those challenges could be addressed well with a "migrating from grid to block grid" article.

Although all the small help labels helped quite a bit, I think the intuitivity of setting up block grid
layouts can be improved. Maybe somehow distinguishing blocks without areas from blocks with areas.

After 5-6 hours of mucking about we're quite content this is an awesome universal multitool we need to seal up well
before handing it to the customer. As the original grid was presented: "the sky is the limit".
However, there is some ways to go still. 😉

Big wishes

Option to render Razor views

The one (really) big thing I miss is an option to use Razor views.
We've become so accustomed to DTGE just "doing it". 👼
Could the "advanced" custom view have an option to just use the front-end cshtml view?
I think a lot of users already hack this in place, ref. Dave's 24 days in article and Lee doing it in contentment.

Given that IsFrontEndUmbracoRequest works in the view we could even conditionally spit out
contenteditable and ng-model/whatever-v-13-brings in them.

Responsivity

Then there's today's big discussion topic: how on earth do we address responsivity?
We quickly realized that we pretty much fall back to one column below some breakpoint with the grid today.
That was easily handled by adding a media query for flexing columns above some breakpoint in the default CSS.

.umb-block-grid__layout-item {
    width: 100%;

    @media (min-width: map.get($grid-breakpoints, "md")) {
        --umb-block-grid__layout-item-calc: calc(var(--umb-block-grid--item-column-span) / var(--umb-block-grid--grid-columns));
        width: calc(var(--umb-block-grid__layout-item-calc) * 100%);
    }
}

.umb-block-grid__area {
    width: 100%;

    @media (min-width: map.get($grid-breakpoints, "md")) {
        --umb-block-grid__area-calc: calc(var(--umb-block-grid--area-column-span) / var(--umb-block-grid--area-grid-columns, 1));
        width: calc(var(--umb-block-grid__area-calc) * 100%);
    }
}

But as others have pointed out in the thread; having editors select / preview how the layout will work
on different devices is certainly desirable.
We've so far concluded we might have one "bootstrap" style block grid and one "freestyle" style block grid.
One allows row span and one don't.
In any case we could do stuff like doubling colspan on medium devices and going full width on small ones.
However there's a glaring opportunity to add several layouts to the block grid data structure.
They should definitely point to the same content collection (and in the future they will be shared).
Alas I cannot see any definite good solution for this. I can only imagine the discussions you've already had at HQ. 😄
Serverside device detection is certainly not something I like.
So I have no conclution for this section, just a big gaping knowledge / idea hole that should be filled. 🤷‍♂️

Small improvement possibilities

• Having a label template so the blocks are recognizable would be nice. (At least until we can see them as razor)
• Allow the same element type to be used for several area type blocks. (See prev. point for distinguishing)
  I can certainly see us wanting to re-use a content block, but vary the possible areas.
  This relates to initial first impression point about distinguishing blocks with- and without areas.
• If we get razor rendering (or in any case) the area editor component should be well documented and re-usable. (See razor section above)
• The convension that all blocks are allowed if you don't select any is not quite intuitive.
  Maybe add a toggle just to make it explicit for the person configuring?
• If an area is set to span two rows - what does it actually span? Should the first block you add fill all of it?
  Feels a bit weird having a "two high" area with a "one high" block inside it.
  It would certainly benefit from feeling more coherent.

Minor nuisances

• There's no blockgrid folder under Views/Partials by default. (Should it appear whenever the data type is used?)
• When making a custom view the DOM leaks outside the container.
  We made a "contenteditable" h1 in a custom view, and the border expanded outside the block container.
• It's really really hard to spot the small square for resizing col-/rowspan.
  I think this is the biggest challenge for first-time users.
  Maybe something like the classic bottom-right diagonal lines or dots would help?
  

Love to see this progressing!
Hope the roadmap stays true and we get the rest of the planned features. 😁

Would be great to be able to had some personnalized properties on the block like. I would like to be able to had "color" and "width" (small, large)