Closed achasmita closed 6 months ago
@achasmita can you please ensure that this PR only includes the humanized/non humanized value changes? Also, I asked for a link to the documentation on hidden columns, and for feedback on visual design from @JGreenlee
I pulled this branch and tested it to evaluate UX.
|
|
I think it is not very clear to the user what the dropdown menu does. When the user makes a selection, they expect to get some feedback; it seems like the displayed table should update, but it does not. I am assuming the dropdown selection only applies to the exported CSV files, but I don't think users will immediately understand that.
If a dropdown is used here, I think it's important for the displayed table to immediately update reflecting this change.
Otherwise, if the options will only apply to the exported file, I think a different mechanism for specifying these options would make more sense. Perhaps a small panel with:
I am also wondering: is it necessary for there to be separate options for each column?
Is there any reason someone would want raw distance with humanized duration? Or humanized distance with raw duration?
If not, this can be as simple as one toggle. Either both 'raw' or both 'humanized'
If a dropdown is used here, I think it's important for the displayed table to immediately update reflecting this change.
The table should immediately update when user select the dropdown option. The new column is added to the end of the table.
If not, this can be as simple as one toggle. Either both 'raw' or both 'humanized'
I like this approach as well. Sometimes too much choice can be confusing ("paradox of choice" https://en.wikipedia.org/wiki/The_Paradox_of_Choice from behavioral econ) We could start with that and make it more complex later
The table should immediately update when user select the dropdown option. The new column is added to the end of the table.
Ah, I see now. I had been expecting it would replace the original column.
If a simple toggle is sufficient, I think a ToggleSwitch would work best. And if the intention is to append new columns at the end instead of replacing the originals, the text for this switch could be something like "Include columns with raw units". And if possible, I think inserting the 'raw' columns immediately after their counterparts would be better rather than putting them all the way at the end.
I also think it would help very much if the columns had their units labeled. Currently, data.distance
gives no indication of whether it's miles or kilometers. data.distance.raw
doesn't indicate that it's in meters. And data.duration.raw
doesn't indicate that it's in seconds.
I liked the idea of switching between either both humanized column and both raw column instead of selecting each column from dropdown. We can use a single button to switch instead of dropdowns:
And the columns get switch once the button are clicked and so does the text on button, This way we can display table either with humanized value or with raw value:
I still need to change the columns name
![]()
@achasmita
Why do you need the trip_id for tables that don't have hidden columns? Can't those invocations remain changed?
Yes it will work if we pass a common id inside dash_table itself, and use same id to reference to trips table . That way we donot need to assign id for other tables.
def populate_datatable(df):
if not isinstance(df, pd.DataFrame):
raise PreventUpdate
return dash_table.DataTable(
id= 'dash-table',
# columns=[{"name": i, "id": i} for i in df.columns],
data=df.to_dict('records'),
I think it looks better than making change in all tables.
@achasmita There is also a merge conflict; please resolve
Squash-merging to address multiple back and forth changes. Please handle properly while merging.
Now trips table includes dropdowns which help user to display, hide and export raw value.
![Screen Shot 2024-01-20 at 10 03 57 AM](https://github.com/e-mission/op-admin-dashboard/assets/79387860/53f58aaa-2bc5-44de-b12b-cc61b0e1ccb0)