ENH: Allow toggling of columns through settings about nextclade HOT 5 OPEN

Related: #112

Yes, I wanted to play with it sometimes. Question of priorities. Not sure how involved that is.

Toggling the columns is probably easy, just need a way to display all that somehow.

Drag-to-resize is quite difficult with the current table implementation. And will likely end up badly.

Column width numbers in settings - simpler in terms of the table implementation, but then you need to write a form and validation for it (what if someone types "foobar", a smiley face or "-145551" there? or what if the numbers add up to something horrible), not even mentioning that that's embarrassingly bad UX.

One alternative thing I wanted to try is the new table implementation: https://tanstack.com/table, which has some of the features that we require out-of-the-box and others seem to be not too difficult to implement.

from nextclade.

Thanks @ivan-aksamentov for sharing your implementation insights!

The reason I suggested toggling is precisely because it should be pretty simple to implement.

If you're worried about validation, what about having a number of predefined radio buttons: off, narrow, medium, wide?

I agree, drag-to-resize looks like a pain, limited settings are what I'd go for.

First in terms of priority, toggling off would be the biggest one I'd think, that'd give people extra space.

Second would be allowing custom columns to come toggled off by default, e.g. we could have two Nextclade pango custom columns: Aliased, Unaliased. Aliased would come toggled on by default, unaliased off. But users can show both, neither or just unaliased.

Third would be allowing wide name columns - I don't think we really need to change other widths as it stands.

Trying out a new table implementation seems much more involved so I'd probably prefer the above. The more involved part of dataset defaults would also be usable by a new implementation, so not wasted.

from nextclade.

I think this would be a great idea. When there are two or more nearby mutations, at least one is often invisible in the mutations column. It even seems impossible, at times, to hover one's cursor over a mutation because its vertical bar is so thin as to be <1 pixel. I've actually moved my cursor one pixel at a time trying to get the nucleotide overview of a mutation and have been unable to do it.

Another idea I think would be fantastic: adding NTD, RBD, and S2 options (beginning S2 right after the RBD for sake of convenience) in the mutations view. This would space out mutations that are often jam-packed in these regions, allowing them to be more easily viewed and examined. If most users are like me, they spend most of their time looking at spike, occasionally viewing the others. I'm pretty sure NTD, RBD, and S2 view options would be #2, 3, and 4 on my list of most viewed regions if they were to be included.

from nextclade.

@corneliusroemer

Second would be allowing custom columns to come toggled off by default, e.g. we could have two Nextclade pango custom columns: Aliased, Unaliased. Aliased would come toggled on by default, unaliased off. But users can show both, neither or just unaliased.

I have no idea how that would work for dynamic columns. Their whole existence depends on input data. What is the "on/of" status and size of "Pango_lineage" for a flu? And how do I know if it even exists?

from nextclade.

@ryhisner great point with creating focused RBD/NTD/S2 views - this should be an issue of its own.

Also, as a workaround you can use the BA.2 dataset of Nextclade (click change, then scroll to second from bottom).

The user settings would have to be dynamically changed based on whatever is in the tree.json - maybe that makes it more complicated. But it doesn't seem impossible to not just make the columns shown depend on tree.json but also the user settings.

from nextclade.