As an Open Data Hub Data Browser user I want to configure the columns I see in the table view, to see the data I'm mostly interested to.

[sseppi]

This functionality will be developed iterating and with growing possibilities to store the choices made by the user.

1. In the first iteration the data won't be stored and the user will have to reconfigure every time his view;
2. In the second iteration the data will be stored in the browser cookies and the user will have to reconfigure his table view every time he changes the browser;
3. In the third iteration the data will be stored in the user profile.

In the milestone 2.3 only the point number 1. is mandatory.

[sseppi]

I share here below an example on how our Ticketing Systems allows the user to personalize column of the the table that shows all issues. We should consider it as example:

[sseppi]

We need the following feature:

• add new column
• remove column
• move columns

For each column the user should be able to choose:

• the value to be rendered
• the component to be used to render the data

In the first iteration we allow only one configuration per user per time. This feature will be evaluated in future iterations.

Open question: how can the user switch between his table view and the embedded one?

A possible solution to be evaluated could be like the image below:

Proposal: per default, if there is a user generated view, the data browser will use the user generated view.

The minimum number of column is one and duplicated/filed columns aren't allowed.

Probably we will need a wizard to manage the columns the user wants to see (by choosing form both configured and not configured parameters) and the order.

Open Question: how do we deal with complex/tree structured data (e.g. License Info of the creenshot below?

)

One possible solution could be to show the tree link in the JSON and allow the user to:

• add silgle values (e.g. Athor, License, 'ClosedData);
• add an entire node (e.g. LicenseInfo) and 4 cloums (one for each value included in the node) are added to the table view

[sseppi]

The user will select only single fields to be added to the Table View through a checkbox near field name.

The selected field will be added in a new list where the user can add other configuration:

• select the order of the columns
• select how to render the values (default is the configuration provided by swagger)
• etc.

The possibility to make one or more column sticky will be evaluated in future iterations.

For the moment each user will be able to create only one configuration stored in the browser. The new configuration will start from the existing configuration, if exist. To start a new configuration from the scratch a deselect all button will be added.

In future iteration we will have the need to identify a better place where to store the new configurations.

One possible way to choose the fields to be rendered could be to use the fileds parameter provided by the API

[sseppi]

Hi all, as agreed in the email exchange I share attached to this comment the PDF file which includes some considerations we did during the last meetings.

2023-OpenDataHub-DataBrowser-ColumnTableView.pdf

Moreover I post here below a comment that @gappc did in the email thread so we have all information in the issue:

"In my opinion this is an interesting idea that has some rough edges that must be discussed, but I see no real show-stoppers if we accept some restrictions.

On the other side we have something working where we just have to decide how a user configures for a TableView the columns to show, in which order they should be shown and how the columns should be rendered. The drawback: it won't be possible to share that user config easily (an idea was to share the config as JSON)

Given that this change will be a lot of work, it is up to NOI to decide if the benefits is worth the effort (unification of generated and embedded TableView, column visibility and ordering as part of the URL but no support). In case we want to implement the proposal, the project planning must be adjusted accordingly"

[sseppi]

Comment by @pkritzinger :

" my technological know-how is way too limited to provide relevant input here 😊 But I will share my opinion on what could be relevant for users:

• The configuration of the table view brings added value to the user – I think we’ve agreed upon this (that’s why I do not further specify it).
  • Sharing the configuration of the table view is of secondary importance, because:
  • Table views may have many different configurations and needs differ from user to user.
  • The Databrowser is not an online-collab-tool.
  • Configuration of a table-view should be rather quickly done.
• On the other hand, it could be relevant for users to access their configurations from different devices. This means, we should try to assure consistency across devices and browsers which is impossible if we store information in the browser.

Anyways, we should choose a solution that is easy to implement and usable/ comprehensible for all visitors of the databrowser. As soon as we know whether the feature is of relevance, we can and should continue to optimize it. "

[sseppi]

For the first implementation we decided to save the configuration in the Browser Memory.

In case of need, we will consider to develop a dedicated "User config API" at an Open Data Hub Level.

@mrabans and @gappc please correct me, in case I got it wrong.