Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Let users manually switch the column type #55

Open
thinkh opened this issue Apr 21, 2020 · 14 comments
Open

Let users manually switch the column type #55

thinkh opened this issue Apr 21, 2020 · 14 comments
Labels
enhancement New feature or request
Projects

Comments

@thinkh
Copy link
Member

thinkh commented Apr 21, 2020

Sometimes user wants to switch the column to a different type (other than the predefined one), e.g., to try different filters. The use case often appears, when users are uploading a CSV file on https://lineup.js.org/app_develop/ and some columns are not detected correctly. At the moment the user does not have the option to change it in the UI. The only option to change it is to open a codepen or similar and edit the column type. This is usually a lot of work for users that "just" want to analyze their data.

In the following are some switches users were requesting:

  • String to date
  • Date to string
  • String to categorical
  • Categorical to string
  • Number to categorical
  • String to link
  • Link to string
  • Boolean to categorical
  • Categorical to boolean

Of course not all switches are possible and useful. We must find a way how we can allow and on the other side restrict this functionality.

Suggestion

  1. Every column has a new menu point Switch column type ...
  2. On click a dialog opens
  3. The dialog provides possible column types (the list needs to be defined)
  4. When the user confirms the dialog the column is replaced with the new column type

Open questions

  1. Is a live preview and reset button possible?
    • Idea: We could place a preview of the new column next to original one. If the user confirms the dialog the original column is removed. Otherwise (on cancel/reset) the preview column is removed
    • If not we should hide the reset button and/or give the user a warning that this action cannot easily be undone.
  2. Which column types can switched into one another?
  3. What happens to categories, min/max values, ...?
  4. Can we keep sorting/grouping/group sorting for the column?

Alternative option

In case this feature request is too complicated, we should think how to improve the importer of the LineUp demo instead so that the user starts with the correct column type after uploading a dataset.

@sgratzl
Copy link
Member

sgratzl commented Apr 21, 2020

since the user story starts with:

The use case often appears, when users are uploading a CSV file on https://lineup.js.org/app_develop/

it should be part of the app and not the library. Moreover, LineUp always had the assumptions that the input data descriptions and data are readonly.

@sgratzl sgratzl transferred this issue from lineupjs/lineupjs Apr 23, 2020
@sgratzl
Copy link
Member

sgratzl commented Apr 23, 2020

Moreover, isn't that similar to the whole taggle-fusion idea?

@thinkh
Copy link
Member Author

thinkh commented Apr 23, 2020

Actually, you are right. I digged in some old issues and I found exactly the idea and a sketch. 😄

Caleydo#7

We started some implementation with Caleydo/lineup#25 (and Caleydo/lineupjs#525), but we never made it to the implementation of this feature, as the focus of the BSc thesis was shifted to the canvas renderer. But I will have a look again what the status of the taggle-fusion branch is.

Would you continue with the taggle-fusion branch or implement it from scratch again?

@mstreit
Copy link

mstreit commented Apr 24, 2020

That's funny. I still thought that this feature would be very useful but I didn't remember that we discussed that two years ago already :-)

@thinkh
Copy link
Member Author

thinkh commented Apr 24, 2020

@mstreit Looks like it is still important to us/our users. Maybe we should really implement it. 😉

@sgratzl
Copy link
Member

sgratzl commented Apr 24, 2020

Would you continue with the taggle-fusion branch or implement it from scratch again?

as far as I remember the original implementation was based on lineupjs-v2 so most likely no

if this feature should be implemented it needs more specification, since it is not a small bugfix but a rather big enhancement / epic

@mstreit
Copy link

mstreit commented Apr 24, 2020

OK, then let's specify it and estimate the effort. Then we can decide if it's worth to be implemented.

@sgratzl
Copy link
Member

sgratzl commented Apr 28, 2020

@thinkh can you specify the ticket in more detail, please.

The main difficulties are that this feature is the first one that changes the description within the data provider. Moreover, when replacing a column there are numerous corner cases, e.g. what if the column is being sorted, grouped, part of a composite, filtered, has multiple instances, ...

@thinkh
Copy link
Member Author

thinkh commented Apr 28, 2020

@sgratzl I will specify this later this week or early next week. Unfortunately, until now I did not have time, due a lot of other tasks. When working on this I will try to think of possible corner cases.

@sgratzl sgratzl added this to To do in lineup May 19, 2020
@sgratzl sgratzl added the enhancement New feature or request label May 19, 2020
@sgratzl
Copy link
Member

sgratzl commented May 19, 2020

@sgratzl I will specify this later this week or early next week. Unfortunately, until now I did not have time, due a lot of other tasks. When working on this I will try to think of possible corner cases.

ping

@thinkh
Copy link
Member Author

thinkh commented May 20, 2020

Excuse my late reply. I try to go through some corner cases you mentioned and write down my ideas. I assume that we will find a lot more once we are in the implementation phase.

The main difficulties are that this feature is the first one that changes the description within the data provider.

Since the loaded data itself does not change when switching the column type, an idea would be to create an additional column with the new type while still keeping the existing one. With both column types at hand we are more flexible and could probably handle some of the following corner cases easier and allow features like reset/undo.

corner case ... if the column has multiple instances, ...

In my opinion we have two contrary use cases here:

  1. Users are focusing on the current column instance and want to change the type of this particular column only
  2. Users are thinking globally and want to switch all instances of this column

I would guess, that the first use case is the most common one, but I cannot exclude the second one. So we might have have to find a solution for both. I suggest the following dialog:

grafik

If multiple instances are available, a separate section is shown in the dialog where the user can select the different column instances. Column instances that are used in composite columns are disabled and show a hint (see next point).

corner case ... if the column is part of a composite, ...

Since the new column type might be incompatible with the composite column, we should not switch them and keep the original column type. However, we must inform the user that a switch of a column within a composite column is not possible. Furthermore, the menu item should be hidden in this case.

corner case ... if the column is being sorted, grouped, filtered, ...

I agree that these settings cannot be converted to the new column type or the visual result might be confusing for the user when automatically applied. Hence, I would warn the user that some actions will be removed and must be applied manually again.

@sgratzl Could you maybe provide a list of properties that can or cannot be converted? And also which might require further configuration (e.g., number to categorical requires binning)? Maybe it is also worth to create spreadsheet with possible combinations and add the limitations.

As for these required configurations we could configure them in an additional dialog behind the cogs icon. Alternatively, if the configuration is not too complex and detailed, we could try a similar solution as we have it for the color mapping.

grafik

@sgratzl Please let me know what do you think about this? Are there any open issues and questions?

A general remark for the upcoming the implementation: Please implement this feature in a way that we can re-use / integrate it also in tdp_core and make it available in our applications. Thanks.

@sgratzl
Copy link
Member

sgratzl commented May 20, 2020

lets start a document since this one is getting too big to keep up:

https://docs.google.com/document/d/1pphg0NTyGKXADCJGahxFdYW9iyTr4xFNC1-HJjVJVfc/edit?usp=sharing

@thinkh
Copy link
Member Author

thinkh commented May 20, 2020

Good idea! I left some comments in the document. Let's continue over there for now.

@sgratzl
Copy link
Member

sgratzl commented Jun 17, 2020

@thinkh so what is the plan?

@sgratzl sgratzl removed their assignment Aug 30, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
No open projects
lineup
  
To do
Development

No branches or pull requests

3 participants