-
Notifications
You must be signed in to change notification settings - Fork 2
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
Comments
since the user story starts with:
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. |
Moreover, isn't that similar to the whole |
Actually, you are right. I digged in some old issues and I found exactly the idea and a sketch. 😄 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 Would you continue with the |
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 :-) |
@mstreit Looks like it is still important to us/our users. Maybe we should really implement it. 😉 |
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 |
OK, then let's specify it and estimate the effort. Then we can decide if it's worth to be implemented. |
@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, ... |
@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 |
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.
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.
In my opinion we have two contrary use cases here:
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: 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).
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.
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. @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. |
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 |
Good idea! I left some comments in the document. Let's continue over there for now. |
@thinkh so what is the plan? |
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:
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
Switch column type ...
Open questions
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.
The text was updated successfully, but these errors were encountered: