opendesigndev / octopus-specs

Octopus format specification (OpenAPI)
https://main.d215pdpdn4c7ow.amplifyapp.com/
2 stars 3 forks source link

Styles in Octopus research #46

Open scoiatael opened 1 year ago

scoiatael commented 1 year ago

In GitLab by @janroztocil on Apr 21, 2021, 19:24

Styles - Octopus representation research

Some form of (shared) styles concept is present in Sketch, Figma and XD. The following text summarizes the implementation specifics in particular source tools, and then proposes a format of representation in Octopus.

The main goal of this initiative is to extract the shared styles information into one place (single Octopus-like file). Currently, styles are copied in every Octopus document that references them. That is far from ideal, the data are duplicated and it's hard to do any high level reasoning of how the styles are used within the design.

Sketch

In Sketch there are two kind of styles: layer styles and text style.

A single 'Layer Style' consists of a arbitrary combination of a fill, border or any other effect on a layer.

Text style is a standard text type format configuration (font face, font size, line height, letter spacing, alignment...).

Both style types can originate directly in the document or be part of a library (which is part of the design anyway).

When a layer has a style assigned, this style can be overridden in the instantiated symbols.

Extra Sketch features is so called "Tint" - which kind of overloads most of the layer's style configuration. However, as it can only be applied to symbol instances or group layers and does not manifest any "shared" properties, it probably doesn't need to be considered here.

Octopus implications

As the current format is based on the Sketch not many changes are needed. Probably only better separation of the two style types.

Figma

Figma recognizes 4 styles types: color, effect, text and grid.

Color style represents a single raster fill configuration, i.e. it can be a solid color, gradient or pattern, which can be used as a layer or a border fill. (It seems that other border parameters like width, alignment or dash pattern can't be configured as a style - of any type).

Text style is standard text type format configuration as in Sketch.

Effect style could be an arbitrary Figma layer effect (drop/inner shadow or layer/background blur).

Grid style is just a named grid layout configuration.

Figma also allows to add description to the style.

Styles can be design local or teams shared.

Octopus implications

  1. Color style requires the new type of style object in Octopus, it can't be put into effect object as a single "color" can be applied to either fill or border. Probably a colorStyle object that would consist of one of color, gradient or pattern Octopus objects.
  2. Grid style needs to added.
  3. Description field needs to be added.

XD

XD uses color and text styles. Color style is basically the same as in Figma (pattern is not allowed here). And text style is the same as in all the other tools.

Interestingly, XD doesn't keep any explicit mapping between styles and places where the styles are applied to. So when editing a style, every entity in the design that shares the same style configuration (color or text) is being changed as well, no matter if the style has ever been applied to the entity or not.

Octopus implications

None, as long as the new colorStyle object is added.

Octopus proposal

The styles file would basically be a valid Octopus document. Although the specification needs to be slightly updated, so that for example layers field is not required. Such setup allows for the styles to be part of artboard Octopus document as well be a standalone file.

Proposed changes

  1. add explicit layerStyle object to represent the whole layer/effects configuration (currently effects is directly in style)
  2. blendMode and useLayerBlendModeOnly are only present in layerStyle object, if those are part of a single style (as it might be in Sketch), both layerStyle and textStyle object are there as children of style (same applies to a style that would combine text formatting and layer effects - e.g. drop shadow, dunno what is the type then thought)
  3. add source field to represent the origin of the style, could be document or library (may be more, like Figma team)
  4. add sourceId as a formal identifier of the source (library ID or team ID), is empty when source is local document
  5. add description field
  6. add style.colorStyle to satisfy Figma and XD
  7. add style.gridStyle as it comes from Figma

Meta-example

Here is a commented example, most of the inner fields are just standard Octopus representation. Hopefully this is sufficient to get the idea of the updted format for now, latter we will update the formal Octopus schema.

{
    "version": "same-as-in-normal-octopus",
    "sharedStyles": [
        {
            "id": "style-ID",
            "type": "layer|text|color|grid",
            "name": "human readable style anme",
            "description": "description added because of Figma",
            "source": "document|library",
            "sourceId": "id of library or team or any other relevant source identification, can be empty",
            "libraryName": "just meta information",
            "style": {
                "layerStyle": {
                    "effects": {
                        "standard-octopus-effects-config": ""
                    },
                    "useLayerBlendModeOnly": false,
                    "blendMode": "NORMAL"
                },
                "textStyle": {
                    "text-style-config": "same as defaultStyle in Octopus"
                },
                "colorStyle": {
                    "color": "rgba color",
                    "gradient": "gradient setting",
                    "pattern": "pattern setting"
                },
                "gridStyle": {
                    "grid-layout-config-as-in-octopus": ""
                }
            }
        }
    ]
}

Next Steps

scoiatael commented 1 year ago

In GitLab by @rychlis on Jun 24, 2021, 10:42

Also specify how are we going to represent that a layer is using specific style

scoiatael commented 1 year ago

In GitLab by @nikitamironov on Jul 13, 2021, 24:15

Good job, nonetheless there are few more notes:

1) Octopus layer styles are not only properties we have under effects key. Layer styles' affected properties are also:

2) Figma fill. Regarding what you said here:

Color style requires the new type of style object in Octopus, it can't be put into effect object as a single "color" can be applied to either fill or border. Probably a colorStyle object that would consist of one of color, gradient or pattern Octopus objects.

I am not sure I understand what is the problem. Do you mean that having effects.fills as array is a problem and we need to have some way which let you to set up only one fill?

  1. Description field needs to be added.

This should be added in octopus-manifest.json I suppose.

3) Regarding XD

Interestingly, XD doesn't keep any explicit mapping between styles and places where the styles are applied to. So when editing a style, every entity in the design that shares the same style configuration (color or text) is being changed as well, no matter if the style has ever been applied to the entity or not.

Mind-blown. This is so messy approach, imo.

4) Regarding octopus proposal: I am not sure I understand some points, we probably should arrange Zoom meeting to discuss it. Nevertheless, combining meta-info (description, library metas etc) imo should not be part of "chunk". All meta about design structure should be in octopus-manifest.json while chunk file should contain only pure style representation and id.

scoiatael commented 1 year ago

In GitLab by @janroztocil on Jul 13, 2021, 11:07

The latest proposal with concrete octopus example is in https://gitlab.avcd.cz/backend/octopus/-/issues/48

  1. I don't know if this is still true (for Sketch), I created a layer style and it seems that opacity and blend mode doesn't propagate into applied styles "instances". May be that was some legacy Sketch feature. But anyhow, it would be possible to encode properties that are outside of the effects object, see the proposal (it's not explicitly shown there but there's a place for that).

  2. I think it's well shown in the proposal.

  3. Yea, that's XD thing, we can't do much about it, I guess we will just list the known styles but without the back reference :shrug:

  4. That's possible, from a format normalization perspective it's even better to have the data only in a single place. However, I wasn't sure how it will be used, whether there's a possibility of distributing styles octopuses without link to the manifest, I don't have strong opinion on that.