As a databrowser visitor i want it to be clear if i can edit the main image and how

[d3liaa]

Now in the main section, the logo image is editable but not the main image. I understand that it can be changed in the image gallery, but in my opinion, that is not easily understood by the user.

We should inform the user maybe with a hint that the first image of the image gallery is the one displayed there, so they can change it, add a new image or maybe just change the order of the images they already have

[gappc]

@d3liaa, @pkritzinger, @Mazzolintis, @sseppi : as shown in the designs, we have the possibility to add a tooltip to provide additional information to users (see screenshot below). Would that be a way to add the missing information? If so, what should the description text be?

[pkritzinger]

@gappc @d3liaa we've foreseen the tooltips for exactly such cases, i.e. saying that Main image is a reference of the image table and can be changed there or ODH Tags is a getter from SMG tags, etc. But we never went into detail regarding this because we would probably have to:

• Identify all attributes where we want to provide additional information
• Define additional information
• Define where information is saved

[sseppi]

@pkritzinger @gappc @d3liaa yesterday I had an internal meeting and there it emerged that, for our strategy, it will be important that the Data Browser have a standard behaviour for all Datasets.

For this reason we should avoid to have custom logic of texts hardcoded in the Data Browser code. So, in my opinion, we should do the first two steps suggested by Paul and then, knowing better what are our needs, see what we will document in the API (e.g. Open Data Hub Tag vs SMG Tag that is a custom behaviour that will be removed in the API version 2.0) and what we will put in the Data Browser (e.g. image is a reference of the image table that is a standard behaviour that we will apply to every image gallery)

@mrabans what do you think?

[mrabans]

@pkritzinger @gappc @d3liaa @sseppi Shouldn't we put also this additional information on a list in the metadata API.

So we would have to decide on how those additional attributes should be called, something like with inside ["attribute1" : "description, xyz", "attribute2" : "description xyz", ... ]

The databrowser could do a lookup for all attributes descriptions and fill the info boxes. If there is none, no additional info shows up.

[gappc]

@mrabans interesting proposal with some corner cases, because there is not always a 1:1 mapping between attribute and component that renders that attribute.

See for example the configuration for the article dataset:

...
component: CellComponent.ArticleTypeCell,
fields: {
  type: 'Type',
  subType: 'SubType',
},
...

This is part of the config for the Article Type visualization (e.g. outcome see here https://databrowser.opendatahub.testingmachine.eu/dataset/detail/tourism/v1/Article/F2743E1C-158A-4B39-B6EB-8987DF61D844#article-details).

The config states, that in order to render this part of the data with the ArticleTypeCell component, the fields/attributes Type and SubType from a given record shall be passed as attributes type and subType to the ArticleTypeCell component. In other words, this defines the data mapping for this part of the record.

Taking this example, it is not clear how to define the such that it is possible to match the information from the MetaData API with this configuration. There are several possibilities, but we need to find out which one is best.

Please note: this problem also arises when we want to merge information from OpenAPI with embedded configuration (see #315), so I think we should put a bit of effort into finding a good solution.

[sseppi]

@gappc @mrabans I see a lot of discussion around the MetaData API, what about having a brainstorming session all together to put on the table all ideas we have and create a plan?