Feedback for Components, Image Property and Value Property

[sinanisler]

Started testing the components. First of all great work team well done

Time to polish this for prod use.

Feedback 1:
Image propery only connects to the Image element. (but image element is not the only place we can show images)
I build lots of image sections with background so I can put text or other elements top of the backgrounds. I think using css backgrounds very common I dont need to write much examples about this.

Image Property needs a possibility for connecting to Background Images.

Feedback 2:

Yes we want to lock the users for sizes, design decisions and styles when creating components. But I think we need one more property for some edge cases.

Value Property
With value property we ca nconnect the font-size, spacing, width or height for rare cases that we need to give control to the user.

Doesnt matter how PERFECT the components are clients always needs more control in some edge cases. I think Value Property and ability to connect to the most or even all css fields can solve this issue and gives us more freedom to create powerfull components.

Feedback 3

Advance Dropdown Property for static select list and ability to connect anywhere text or image (and maybe values?)

just like form dropdown select field we can add only static options so user can select the existing texts or images.

last year we were giving some development support for one of the biggest german brands they were using adobe cloud sites on there they had lots of existing components some of the components didnt even have freedom to change texts because they have determined and finalized mottos, slogans, posters or brand titles…etc
when building pages we were only able to select existing assets for those components.
On enterprise level this is very common because changing one color or even one title on a page needs to be approved every time.

[Bulga]

I came to report the same thing. Why forget the background image.

[Dawson]

Points 1 and 2 feel absolutely necessary and point 3 would be a fantastic feature

[brendyn]

There’s a couple of things missing to take it to the next level.

1. A “value” field as you suggest will do a lot of heavy lifting. For example it’s quite common to have to override the top padding in a section to tweak space between elements. Having a value field would let you insert a default and then override it easily. That would let us use the same section component without having to make a second copy that has no padding at the top.
2. The ability to use the values in conditions for items in the component. If you were to combine that with a true/false toggle property field type and a select dropdown property field type you could do some amazing things that would be really client friendly.
3. Lastly it would be nice to have some organising in the component view - e.g. a button needs a link and text property - it would be nice to be able to visually link these and separate them from the other properties visually.

[kyle-gs]

Agree with the suggestion for a ‘value’ field, or some way to expose settings for the style & layout properties.

I’ve installed it locally and started to work with the new components feature, which I’ve been very eager to use. My first thoughts:
The interface and workflow for editing are, on first pass, really beautifully designed and implemented. Creating, editing, and exposing properties was all absolutely seamless. Fantastic job here, Bricks team.

A few other features I would love to see implemented:

• nested components: this one is big for me. A simple use case is creating a branded button with an icon and hover animation, and then nesting that into a card element… but many other & more complex use cases can be imagined for a fully components-based system

• conditional elements which can be toggled on/off (might have missed this, still exploring)

[Illarion]

My rant about components is that we can’t see an actual dynamic tag used for property.
For example, in JetEngine components when I create a property I got something like {je-component__my-property-name} and then I can include it wherever is dynamic data supported, and the most important in condition rules.
Bricks components are very limited at current state.

[sinanisler]

I am still not sure about nestable components
I am on the fence for that one

but all the other recommendations everyone spot on.

[Matej]

Hey all,

thank you for your suggestions. I’ve read through all of them and they are great. I’ll present them to the team, so we can decide about them

@Illarion, I’m just not sure if I understood your suggestion completely. What do you mean you can’t see the actual dynamic tag used for a property?

Thanks!

[Nora]

I am also unclear on the use case for nested components. This initial implementation is simple and clean. Fantastic that editing is done in situ. What is the value proposal for nested components (I worry about complexity for the sake of fun).

[Panag]

There are definitely a lot of use cases for nested components, and flexibility is key! They can make editor editing much smoother and more intuitive. Here’s an extreme example from a Webflow user that shows the potential: x.com.

[wplit]

@Nora

the use case for nested components

You may have whole sections or areas of the site be components as they’re being used multiple times and always need to be synced. (testimonial section for example),

Within that section you might include something like a large CTA button that is also being used elsewhere.

Ideally, you’d have this as a ‘button component’ inside the ‘testimonal section component’, so you could make edits to the button inside that section, knowing it’s being changed everywhere else where it’s being used also.

For example, you need to change the icon for all CTA buttons on the site, regardless of where they’re being used, even when inside other components.

[Illarion]

Hi @Matej

I create a control (property) for component:

And I can choose it in dropdown and put anywhere, incuding conditions

It similar to bricks, but in bricks it’s predefined with ‘plus button’, which is a bit limited

[Matej]

Hi @Illarion,

oh, yeah, thanks, I get it now So, the ability to use “special/component-specific” dynamic tags inside the components.

That is something that already crossed our mind, but I’ll make a proper idea entry in our tracker, then we will see It’s definitely useful.

Thanks,
Matej

[sinanisler]

was testing stuff. found a issue.

only content role given editor users able to edit the component properties. not good.

only content editing role should only able to edit the content.

[PandaGerrie]

After my first try I have a some feedback / Ideas too, as wel as a question.

Feedback:

1. Would be very nice to be able to open and close component properties when editing an instance of the component. Making these behave like accordeons:
   
2. The value property as described above would be awesome, as well as some style variables like color / bg color etc.
3. I love these components, but for my team to really start using them, we need a lot more options in the properties. Baby steps, I know, but at this moment the use case for agencies are very slim. Still love the work that has been done so far!

Question:
I made a component to simulate ‘team member cards’, all very basic.
If I want them to display next to each other inside my ‘flex’ in 3 collums, but I have 5 cards. What do I do best?

• I don’t see an option to set the width of the block on component instance level
• I can set the width on the component level, but what if I want to use the same block on twe different places, one time in 2 colums and the other time in 3 colums? How do I overwrite that components width (or other props) on instance level?

[brendyn]

Another thought would be if a new “value” property was a bit more development and therefore the timeframe was a while away, would be to enable certain extra properties values for editing in the current properties.

An example would be the image component. It would be amazing to be able to make the “object position” field editable for images.

That would make image layouts MUCH more adaptable within a component by providing the end user the ability to set a custom object position for an individual component instance rather than having to apply the same object position to all instances.

[Matej]

Hey all, time for another check up

@sinanisler

only content role given editor users able to edit the component properties. not good.

Yep, you are right. I’ve recorded this into the bug/idea tracker. To me, it would also make sense that “Edit content” right does not allow editing the component properties.

@PandaGerrie,

@PandaGerrie

Would be very nice to be able to open and close component properties when editing an instance of the component. Making these behave like accordeons:

So basically “groups”, like it was suggested here, right? Feedback for components: collapse properties panels and group them

And to your question:

@PandaGerrie

I made a component to simulate ‘team member cards’, all very basic.
If I want them to display next to each other inside my ‘flex’ in 3 collums, but I have 5 cards. What do I do best?

You will have to use custom CSS, or wrap individual instances in div/block, and then design that block. Properties are currently not supported for CSS controls.

@brendyn

@brendyn

An example would be the image component. It would be amazing to be able to make the “object position” field editable for images.

Yeah, that will be possible once you are able to connect properly to the CSS control. This is sadly not the case now, but it’s an improvement that we have in the internal roadmap

[Maexxx]

@PandaGerrie

I can set the width on the component level, but what if I want to use the same block on twe different places, one time in 2 colums and the other time in 3 colums? How do I overwrite that components width (or other props) on instance level?

• You use a wrapper element with CSS grid and define the two or three column grid there. Assume your items inside the wrapper/grid are cards.
• The only use case where you define a width on the card, would be auto-responsive cards, which automatically adds as many cards in a row as your max-width allows. If the wrapper is narrower, fewer cards fit until one card wraps the whole row/available container width.

[wplit]

+1 for a ‘value’ or ‘number’ property type. (that can be used with number settings like number of slides per view etc).

Also ‘gallery’ type.

[cmagill]

I’d say images should also come with Object Position/Background Position properties. The focus point of the image is more tied to the image itself than the overall component.