Make functionality for adding custom metadata

[VladimirLevadnij]

Hello, the discussion of this issue started in another topic #462

By agreement with @niwinz, I created the current request, I’ll write more here.

I propose to create custom metadata functionality that can be added to any entities on the workspace.

This functionality will be useful in many Penpot usage scenarios. Including:

1. Temporarily replace the plugin system that Penpot does not yet have and make a high-quality, stable, functional plugin system is a task that requires a lot of time and effort.

2. Improve the ability to integrate Penpot with other services, both within the framework of export and import of projects.

3. To be a universal solution for correcting current shortcomings in the Penpot logic.

I will write more later on how the user metadata functionality can solve the above questions. Now I will describe the essence of my proposed solution.

I suggest for each element of the workspace to make it possible to add custom metadata. And also, for the convenience of managing metadata, make another section "Metadata" in the assets. That is, in addition to Component, Graphics, Colors and Typographies, there will also be Metadata (or Custom metadata).

In the first step, you can bind metadata only to components. But it would be more correct to make it possible to make custom metadata for any object.

When selecting an object and opening the drop-down menu, you need to add the "Metadata" (or "Custom metadata") item there.

This window can be modal:

But if you follow the existing design, you can make the desired functionality in the right area, for example:

1. As a third tab.

2. As another block on the first tab.

For each metadata field, for convenience, you need to make a "title" (required field) and "description" (optional field). And the third data field. I think that the data needs to be made of several types. To start:

1. Boolean. For simple true/false logic.
2. Text. You can insert a large amount of data in any format.
3. Label. A special string data format with a limit of 10-15 (or 15-20) characters, in order to make label (marks) functionality in Penpot based on this.

If we talk about a more extended list of field types, then you can also make the JSON format (separate from the text format), you can see how it is implemented in Strapi. You can implement at least the ones I highlighted in the screenshot, but you can also implement various other data types.

In addition, below I will write how and why to associate the comments functionality with metadata.

[VladimirLevadnij]

Now let's discuss the different uses for the custom metadata functionality I'm proposing.

In the beginning, I want to briefly talk about my professional experience. Now I won’t talk for a long time about the fact that we, with like-minded people, are now gathering forces and technologies to help people around the world fight against imperialist governments and corporations, and so on :-)

Now I will talk about something else. I had experience, I worked as a project manager in the largest transport and logistics company in Russia. Larger than we were only the state Post of Russia. I had a lot of projects with poor and unstable integration, but it was necessary to quickly resolve issues that had been accumulating for many years.

Hundreds of different departments with thousands of employees that are located in 11 time zones and work around the clock, without stopping, demanded from me quick solutions that should be implemented "yesterday". We had a work plan and had a lot of money and specialists. But even with a lot of money and a lot of specialists, in the field of automation, especially within the complex internal decision-making structure of a large corporation, you cannot quickly make everyone feel good right away.

In order to somehow solve the situation, although temporarily, I developed a list of architectural solutions that allowed me to give everyone some tools that allowed me to solve the needs "right now". One of such decisions was the introduction of the universal entity "metadata". In that case, the implementation of the metadata was more complicated than what I propose now for Penpot. But such functionality allowed me to give everyone who filled me up with "urgent orders from the most important director in a particularly important area" a tool that they could use in different scenarios, primarily for data integration for business intelligence, as well as for various other tasks.

Then, when more complex automation was done, in some cases the need for user metadata disappeared, in some cases it was saved.

Summarizing what I wrote above. More and more people and organizations will resort to the Penpot repository and ask / demand / persuade to make some kind of functionality they need for integration, for export or easy revision of the front, without creating new structures in the backend.

We need a universal mechanism that will allow everyone to give the right tool, even if not the best in all cases, but existing right now, allowing right now to realize the needs of users.

I understand that without the functionality of the REST API and without the functionality of the GraphQL API, the metadata functionality will now be difficult to use.

But, firstly: for some teams, those who use Penpot locally, at the current step it will be enough for the first steps to understand how to use the RPC API.

Secondly: having implemented the metadata functionality, you can use it to improve various functionality.

Thirdly: I don’t know at what stage of development the possible functionality of Penpot plugins is now, but I know that it will take a long time to make stable and reliable functionality of plugins. Therefore, it is possible to implement metadata functionality that can partially replace the functionality of some types of plugins, for example, integration plugins. And to focus on the development of basic functionality, stability, API.

Then you can implement a full-fledged plugin system. Including, if necessary, it will be possible to move the functionality of user metadata into a separate plugin. Some conversion of the old data will be required to transfer this from the internal structure to the plugin structure, but this is a technically feasible issue. But maybe there will be no desire to take out the custom metadata functionality in a separate plugin.

I'll add more. Thinking about who can be a Penpot user, I think that in addition to ordinary users, Penpot will be of interest to companies that have a high level of corporate security. There are many such companies in the world. Security rules prohibit the use of cloud services in such companies. In this case, Penpot for them is an opportunity to make their own "Local Figma". I think that companies will be willing to pay for support / professional advice on the operation of their local version.

In this case, it's good that Penpot already has the Authentication Providers connection functionality. But it will also be important to create a functionality that allows you to refine the Penpot for corporate purposes without unnecessary programming, through configuration. In this case, creating custom metadata functionality is a step in the right direction.

I don’t want to say that many companies will come running tomorrow and shower everyone with suitcases with money 😸 But the ability to configure the system is a functionality that is useful and in demand, both by individual users and companies.

[VladimirLevadnij]

As I wrote earlier, the metadata functionality can be used as a universal mechanism, including for creating the label (marks) functionality.

This functionality can be conveniently used to label various objects on the canvas, including the Artboard.

For example, labels: "Important", "Replace", "Check" and so on.

In the interface, it will be possible to make filters by label so that objects with the selected label are displayed.

When an object is selected, a block with its labels can be displayed in the right area, either separately from the metadata block or in the metadata block.

Artboard labels can be shown right next to the title or below the title. You can only show the list of labels that fit in the width, and the rest of the labels can be seen in the right area and by pressing [...] Additionally, there can be a setting whether to display labels next to the Artboard name, or display only when selected in a block in the right area.

[VladimirLevadnij]

The metadata functionality can be used to bind comments to objects. At the moment, as I understand it, comments are fixed on the canvas at hard-coded coordinates.

Because of this, it turns out that I could write some kind of comment, for example, "We need to change the color of the button." I put this comment next to the button that needs to change the color.

As I continued to work, I could move this button or generally reorganize the objects on the canvas, move the objects around. But since the comment is fixed on hard-coded coordinates, the comment may be far from the button next to which I put it.

It would be even worse if it turned out that there was a completely different button next to this comment.

Such problems would not exist if comments were attached to objects, for this you can use the universal metadata mechanism.

In such a case, when hovering over an object, that object should be highlighted to indicate that it is active under the commenting cursor, when clicking on setting a comment, such a comment (comment block) would create an anchor in the object's metadata. The object could be moved later, but the comment icon would still be shown in the upper right corner of the object.

At the same time, you can keep the ability to put a comment directly on the canvas, while binding to the coordinates on the canvas will be carried out.

This raises the question, it turns out that all written comments, since they are elements of user metadata, will be displayed in assets? I think comments should not be shown in assets because comments have their own section.

And if we talk about the fact that assets help to reuse the same elements, then we still need to proceed from the fact that there will be label functionality for reusable use, and comments (blocks of comments) should apparently be separate.

Therefore, there should be functionality in user metadata that allows you to make sure that comments do not fall into assets. Usually in such cases, when there is a functionality of fairly universal entities, they add the ability to make some elements hidden. Hidden entirely from the user interface, or hidden until the user clicks the "Show Hidden" button.

Assuming that users should have more options for fine-grained control of all objects. In this case, you can make it so that the user, if he has such a need, can still click on "Show Hidden", but in order not to break the logic, he should not be able to edit the fields in the metadata elements that are associated with the comment. Only delete. It would be useful not to go to the comments section, but by performing various actions in the metadata block, along the way, also delete the comment block if it is not needed.

Therefore, in order for the user to not be able to edit such a metadata element, we will need one more parameter that will not be available through the user interface. This will be a boolean field. You can call it "Editing", you can call it "System", or something else.

Then, the user will be able to create their own hidden metadata elements, or this will be done by the developers of UI Kits, templates, and so on. Hidden items will not show up in assets.

And metadata elements that cannot be edited can only be created in a system way, for example, by the comments functionality.

[VladimirLevadnij]

Also in another post, I wrote that, for example, the metadata functionality would be useful to me and many other users in order to use Penpot as the first stage of the nocode platform, so that, for example, buttons and other UI elements have metadata in which the name is marked UI libraries (eg Material Design) that this is exactly a "Button", various additional options.

#462 (comment)

[superalex]

Hello!,

Thank you very much for such a detailed request, it's great and really useful for the team :)

I've just opened an enhancement at Taiga with all your information to track this issue from here. Hopefully, we will start to work on it soon.

Regards

[VladimirLevadnij]

I will add information on the label (marks) functionality. This is an example of how the display on producthunt.com is implemented when all elements do not fit in the width.

[VladimirLevadnij]

I will add information on the metadata functionality. Assuming that custom metadata can be added to any object, then metadata can be added to a group as well.

It is necessary to work out the logic for those cases when objects are ungrouped, that is, the entity of the group is deleted. In this case, there are the following options:

1. Inform the user that ungrouping will remove the user's metadata.

2. You can pass custom metadata from the group to the "base" / "bottom" object of the group. You can also inform the user that if he continues to ungroup, then the metadata will be transferred to one object of the group or all objects of the group (you can choose).

[VladimirLevadnij]

Also I think that there should be a metadata option that will be system, not user, so that the user cannot edit and cannot see this element of additional metadata. This can be useful for creating various functionality and it is necessary that this metadata does not scare the user with its presence, does not make the user think why it is needed and what to do with it.

[VladimirLevadnij]

I wrote about how custom metadata can be added to any object on the canvas. That being said, it should be clarified that adding custom metadata to pages is also a useful feature.

[Rodsevich]

This would be awesome. Is it scheduled?