Skip to main content
Version: Next

Open Questions

Do we store all changes of parameters of a layer as separate actions, or bundle them together?

  1. Initially there was a consideration to define “action keyframes”, and an example of what is not a keyframe: moving an object on the screen to its final position

Right now we package .replay files as ZIP - however this is not the most efficient way

  1. Artur Gevorgyan This is not the best conversion algorithm, there much more efficient ways to compress files, gzip, Brotli
  2. Lucian Tuca Agree, zip might not be the best. I think the decision of choosing .zip was based on multiple factors, like users being able to rapidly unpack when required. I think we should pick the algorithm based on the most used case. If we have huge packages and need to pack/unpack them really fast, we can change it. If we just need something that's easy to unpack, zip is fine.

How do we lock reordering of canvases? How do we lock reordering of layers in a canvas?

  1. Use-case from Aram Mkhitaryan: e.g. there is a business card with the front and back sides. By design, you should not be allowed to make front as back and back as front, etc.For the video/ad format, you can consider a case when the creative team ensures with locking that the intro canvas is not modified (not the content, and not the order in the list of canvases)

How do we define Subtitles (tech doc) using Text object? How do we define a fixed font size?

How do we define top-level Background?

It is essentially just one prop for defining the Pattern

Use case for “exportable” setting at layer level

  1. Aram Mkhitaryan exportable stands for form factor elements such as guidelines, rulers, social buttons, etc, that we may need/want to show, but not export
  2. Artavazd Mehrabyan the rulers, etc are not exportable by default, please provide more details on how this property is used.
  3. Aram Mkhitaryan question: are we going to use these object definitions to define rulers or those will be different type of definitions?
    1. the idea here is that if we use the same object definition and the same format to define the ruler, then we should have the tool to say that "this /ruler/ object shall not be exported"
    2. otherwise, if the idea is to add a new object type "ruler" (like we have image or sticker or text) then we can as well have a convention that the "ruler" type is not exportable at all
    3. another use of this is a case when the "designer" may define a rectangle and say that the marketing dept shall not add elements outside of that rectangle
    4. so the marketing dept will see the rect, will be able to align elements with that layer, will have the guidance, but when exported, the rectangle won't be exported
    5. (will jump ahead and say that I agree that this same result may probably be achieved using rulers, but maybe not ...)
  4. Artavazd Mehrabyan to me, this looks overengineered.
  5. Artur Gevorgyan The above mentioned use cases are all not part of the actual rendering and they are considered as tools on the side of the editor. and they are even environment dependent(e.g. watermark). In our web editor so far we had one single rule, if something is not exportable it is not serializable. So In any of the above mentioned cases the tools are not even in the canvas. I assume this is like serializing a transformer. So let's remove this property
  6. Aram Mkhitaryan
    1. the difference between the transformer and watermark vs the guidelines and rulers and such is that the end user defines the latter and wants to keep that until the end
    2. agree that maybe the form factors, layout previews and similar stuff are closer to the watermark experience and maybe we can keep that apart and not serialize
    3. here we will just need to make sure the "format" is written in the replay, so e.g. we don't say it's a square design with 1080x1080 pixels, but we say also that it's a instagram story or post or something like that
    4. this type of information can be saved as a meta or settings
  7. Artavazd Mehrabyan it is too custom use case specific, and these all can be put in meta
  8. Aram Mkhitaryan not custom at all, this is not like the isi. as this gets implemented, it will be used in almost any design
  9. Artur Gevorgyan The required assets are also platform-specific, e.g. any asset which is hoverable is not possible to represent in mobiles(e.g. hover highlighting in web). Another case the transformer looks differently on different platforms.
    1. On the other hand I assume it is possible to define a transformer layer with our format, but it is not possible to serialize the behavior of that specific layer, without explicit coding.
    2. I'll stand on removing the properties and apply the assets as we had so far, as a part of the vanilla editor. cc: @aram.mkhitaryan@picsart.com
  10. Artavazd Mehrabyan let's skip this for now

How to store resources in the .replay file

  1. Istvan Kovacs: the resources folder is for local storage of resources.
    1. Example 1: saving a template/project to disc (in .replay file) with all resources downloaded. In this case all resources locations will be relative paths like "/resources/..."
    2. Example 2: saving b2b clients data in .replay file when they open a template & add personal photo & choose to print
  2. In this case the template resources will be pointing to picsart CDN, but the b2b client (client of our client) photo will be relative paths like "/resources/..."
  3. As per the discussion on the 27th Feb, we need to investigate if the support for binary resources storage in the .replay file is a requirement or not. Alternatively one could always upload resources to our picsart or any other server/service, and only reference via URL. Aram Mkhitaryan, Maximiliano Spika please consider this and let's discuss on a call with Artavazd Mehrabyan if it's needed. note: we know that NOW this is used in B2B cases and is also the way to store multi-page edits.