Sylius: [RFC] Color attribute

[gabiudrescu]

Products such as bags or make-up can cause big issues without a color attribute. This is required for:

• filtering
• product page
• legal reasons (in case the customer wants to return the product because you stated on the website it was dark red and it was actually bright red)

Given this business requirement, I was thinking to create a new attribute type called Color attribute type, that basically extends Text Attribute, but the form used in product editing page is having a color picker that fills in the Text field with the HEX code.

In front-end, given the attribute type is color, the UI Developer will know to render it accordingly.

How have you tackled this so far?

[okwinza]

IMO there should be description of a color along with the colorpicker. Like Bright Red and so on.
Makes it easer from UX standpoint.

[gabiudrescu]

so, in your opinion, it should be something like an multi-level assoc array: [ "color" => [ "key" = "#ffffff", "value" = "white" ] ] ?

and white should either be manually completed by the operator or completed by referring to something from like CSS color names?

[okwinza]

I think there should be one more field to describe the color. Something like color_hex and color_text. Altthough i haven't dived into new attribute system yet so i'm not sure which way would be easier to implement. But you get the idea :)

Color description should be written by hand and shouldn't know anything about CSS. Because there are plenty of examples where manufactures prefer to name colors in their unique way like Rose Gold and Glossy White.

[okwinza]

Also even tho i think it's definitely good to have visual representation of color i'm not sure about colorpicking approach. It might add a tons of headache for your CM stuff.

Personally i don't see a living being colorpicking every single product lol.

[tristanbes]

Personally i don't see a living being colorpicking every single product lol.

I think the same thing. I never saw color description based on a colorpicker on any shop I know. Might add overrhead.

If there is an approach like [ "color" => [ "key" = "#ffffff", "value" = "white" ] ]

My concerns:

• Translation, will it only apply to value ?
• The value needs to accept any text with not necessarly link to the value of the key.
• It needs to have more than 1 color
• It needs an attribute to display or not on the shop part. (does attributes have that already ?). The goal there is to use certain attributes to search products but not necessarly display those attribute on product info.
• What about having one big Color table with translations. And link multiple colors to the product as an attribute but with the content of this table ? It would avoid having 600 attributes color with value "blue" and his translations.

[peteward]

I thought in default Sylius that Color was more suited to being an option than an attribute?

[okwinza]

@peteward and this leads us to the question of "Why dont we introduce option types like we did for attributes". So we can render different visual depending on type.
WDYT?

[gabiudrescu]

@peteward it's good you opened this discussion up, because after clarifying color attribute, my plan was to open another RFC about color option.

in my context, we don't have yet product variations - we have only masterVariants. this feature is scheduled on our roadmap for next month. that's why I'm talking about the attribute type right now.

why I think we need a color picker is because we need to show in frontend something like this:

Sure, it would be nice to have, on top of the color picker:

• color name with translation
• the possibility to define a pattern instead of a color HEX code by uploading an image
• to be able to generate variations based on the colors available for a product

But all these are in the "Nice to have" section of the backlog.

First and foremost, we need:

1. a filter with colors similar to what I have shown above
2. a color attribute with a visual representation of the color the data entry operator has chosen
3. the possibility to import the color information from our legacy product information manager and map it to a Sylius attribute

In terms of admin interface, we need something like this: https://www.script-tutorials.com/demos/158/index.html

Hope you understand the need better now. What do you think?

[peteward]

We actually went down a different route and created Colours and Sizes as their own entities, partly because of the problem you are facing but also because our business is quite narrow scope of clothes and we have core and sometimes complex business logic associated with them:

• Sizes that are 'grouped' together
• Sizes related by archetype
• Colours that are grouped together (various shades of 'red' which all need to be filtered as 'red').
• Colour swatches and hex values.

However I agree with your principle here that there needs to be a way to extend or decorate Attributes or Options to provide this functionality in a more general way, and it's probably not that difficult, it just needs a solid proposal.

[gabiudrescu]

My MVP proposal for this is:

• create a new attribute type called color that extends basic text attribute
• the formtype for this attribute should have in admin something like this https://www.script-tutorials.com/demos/158/index.html
• when creating filters, attributes having type color will render as shown above in examples from Amazon or other similar websites
• the same behavior for product page - if the attribute has color type, it will render specifically

Admin wireframe:

WDYT?

@pjedrzejewski should we think about this as a potential pull request to core or should we think about it as a custom userland implementation?

---

@peteward I've seen a system where colors have a parent-child relation; there is the color "Red" with a lot of children like "Sweet red", "Foxy red" etc. and each children entity has the following attributes:

• name
• hex code
• picture - optional (for patterns)

And filters are created on top of the parent color, while in product page the child color is used for reference.

The idea is not bad, but I find it very complicated and a bit too much for some simpler use-cases.

[peteward]

hmmm...

The problem here is that you now don't support a name for the colour, only it's hex value. Some people will prefer (or require) different ways of representing something. The colour picker idea is interesting, but it's not the only way to represent a colour.

I think the more fundamental point here is attributes or options that have multiple defining characteristics. In the case of colour it could be Name + Hex or Name + Swatch Image.

Then if you assign the colour 'Red' as your products Attribute, it will inherit all details about 'Red', including it's Hex value. This gives you control in one place so if you wanted to change how red looks, you only change it once, not across 200 products.

[gabiudrescu]

@peteward interesting point of view. I fully agree with it. That would mean we have the following types of color attributes:

• hex colors (extends text attribute)
• name colors (extends text + transation attribute)
• swatch colors (extends entity attribute - does that even exist?) - for example, the one where you have to import a tiny png / jpg pattern.

Is there something generic I'm missing here?

[tristanbes]

This might help, let's say, it proposes the most X color used in your product picture and it propose to use 1-N of those color as attributes ? Could be a smooth workflow there :
https://github.com/thephpleague/color-extractor

(For hex colors only, because I'm +1 with the need of having hex colors / name colors and swatch colors)

[stale[bot]]

This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in a week if no further activity occurs. Thank you for your contributions.