LHS Hit Navigator redesign

[mwinokan]

Following the v2 release and lots of new tags it makes sense to revisit how to effectively display the new data. Please see the attached mockup. The main motivations behind the redesign are:

• Raise the profile of the privileged tags 'CanonicalSites' and 'ConformerSites' into separate columns. These are separate from the curator added tags.
• Increase the readability of observation and compound names with bigger text and make better use of the vertical space
• Quickly see how many observations an entry has

new_lhs_UI_proposals.pdf

[mwinokan]

@matej-vavrek could you please start looking into this one you have finished with the outstanding purple release work?

[mwinokan]

Here's a suggestion for how to adjust the observations table to match:

Outstanding shortcomings/missing spec of the current proposal:

1. 8x1 vs 4x2 grid of [A][L][P][C] etc ... buttons

• In the current draft the hit navigator is the only place where the 4x2 layout is used, conceivably the RHS can be adjusted but it clashes with the narrow rows in the observations table.
• @phraenquex prefers the horizontal button layout but it underutilises vertical space.
• @matej-vavrek do you see a different solution for the hit navigator where we can keep the 8x1 layout?

2. Defining the colour cyclers/ranges

• @phraenquex How many colours do we need to support for canonical sites? If it's less than 10 we have many options. To support up to 20 we could use something like ColorBrewer2.0 qualitative tab10 and tab20 (see here), starting with the 10 bright colours and then using the lighter counterparts for the next 10:

• The above colour cycler could be used for curator added tags?

• Then for the ConformerSites, CrystalForms, and Assemblies we can use a continuous range of colours, e.g.:

  • ConformerSites A range of greens
  • CrustalForms A grayscale range
  • Assemblies A range of oranges/browns

[boriskovar-m2ms]

@mwinokan currently the observations are grouped by compound and canonical site and it seems from your proposal that they should be grouped by compound, canonical site AND conformer site. Is this correct? Because currently this is possible (highlighted row of tags are conformer site)

[boriskovar-m2ms]

Aren't going be the canonical and conformer site tags exactly the same as they are on respective compound that makes it a redundant information?

[boriskovar-m2ms]

It seems that this proposal will make the LHS list a lot slicker but also slimmer which will affect Tag details window which is right above hit navigator so maybe we will need to redesign it too so they can continue to coexist peacefully in the same column.

[mwinokan]

@boriskovar-m2ms I just spoke to @phraenquex and we should not group by ConformerSite, but highlight the conformersite of the displayed observation. I will think of a way to indicate the diversity of conformers displayed across the observations

[mwinokan]

I will clarify the spec/mockup when I get a moment

[mwinokan]

@phraenquex @boriskovar-m2ms @matej-vavrek what do you think of the following to show diversity amongst observed ConformerSites in the hit navigator:

If this is too busy I would suggest just showing the ConformerSite for the displayed/first observation

[boriskovar-m2ms]

@mwinokan I think it looks good

[phraenquex]

@mwinokan agree it looks great. Run it past Daren and/or Ed too.

Probably the conformer stacked column should be over to the right, just left of the orange observations block?

[mwinokan]

@matej-vavrek thanks for highlighting the difficulties with the 2x4 vertical arrangement of the NGL viewer buttons. Please could you explore the following layout:

• Do you think we would be very limited with the text sizes for the observations and compound?
• And could we have a dynamic view for the tags so that they are shortened to the first X characters if the view is too narrow to accommodate them?

[mwinokan]

@matej-vavrek for #1261 could you please add radio buttons to the observations so that the 'main' one can be specified

[boriskovar-m2ms]

@mwinokan for your last suggestion we need also support from backend if this should be target wide for all users

[mwinokan]

@matej-vavrek the radio buttons won't be needed until we decide what to do with #1261

[mwinokan]

Let's discuss at today's meeting, but here is a full mockup including all the various bits of spec discussed in this ticket and #1261 #1392

[boriskovar-m2ms]

Let's discuss at today's meeting, but here is a full mockup including all the various bits of spec discussed in this ticket and #1261 #1392

@mwinokan Here in the picture in the select x0123f and x0123k are already existing poses I guess. What if there is a lot of them in the select? How do we "delete" given pose? When we assign all of it's observations to different poses then the pose should be deleted? The pose name or display_name can be only name of one of its observations or it can be any free form text? If former what if I add observations A to pose B and change its name to A and then remove the observation from the pose?

[mwinokan]

@boriskovar-m2ms

Here in the picture in the select x0123f and x0123k are already existing poses I guess.

Yes that's correct. There should be the option to add an observation to any existing other poses that share the same compound and canonical site.

What if there is a lot of them in the select?

All selected observations should be added to the desired new or existing pose/group

How do we "delete" given pose? When we assign all of its observations to different poses then the pose should be deleted?

Yes, there is no point having a pose with no observations.

The pose name or display_name can be only name of one of its observations or it can be any free form text? If former what if I add observations A to pose B and change its name to A and then remove the observation from the pose?

The pose name should indeed just be the name of an existing observation (for now), and in the case where the observation that provides the name is removed from a pose, the user should ideally rename the pose to a different observation. I think it's ok to leave that up to the curators for now, but @phraenquex may have thoughts.

[boriskovar-m2ms]

What if there is a lot of them in the select?

All selected observations should be added to the desired new or existing pose/group

By the select I meant the select-box or drop-down containing all the compatible poses. What if there is a lot of compatible poses? Would this affect the usability? Can this even happen in the real world?

[mwinokan]

@boriskovar-m2ms

I see. I think just add them all to the drop-down for now. I don't think there will be more than a dozen for any of the current data.

[mwinokan]

@mwinokan to think about how compound aliases (#1262) can elegantly be shown in the new redesigned UI

[mwinokan]

The aliases (#1262) are more important than the default Zinc ID's, so the hit navigator rows should show the compound alias over the Zinc ID if present. The Zinc ID should still be present in the download metadata if the user needs it, and perhaps it can be in the hover or clipboard if the alias is selected?

[mwinokan]

@matej-vavrek is back and is now working on this ticket

[phraenquex]

@mwinokan might be relevant to add something using the mol properties api #1177

[mwinokan]

@mwinokan to talk to Daren/curators to see how we can display useful alias and property information. The search function should also look for matches in this metadata

Maybe a context window/table is more useful than tooltips

[mwinokan]

@matej-vavrek I had a look at your stack, really great progress!

Comparing the mockup:

to your draft:

I think the following improvements can be made:

• [x] the observation shortcode (AX????) and compound string (Z*) should be on separate lines
• [x] Please make the text size as big as possible (within the constraints of the UI), improving legibility will be a big win for the redesign
• [x] If possible please take the colour of the Canonical and Conformer sites from the colour of their associated tags.
• [x] The colour of the observations counter/button should be a colour scale from grey (1 observation) to bright orange (10+ observations)
• [x] Please follow the above suggestions for the observations panel too
• [x] The observations panel rows will also need the 'target'/'center on' buttons, not sure if this will need work from Boris.

I hope that helps!

[mwinokan]

@matej-vavrek please let me know which of the above tasks are technically difficult, we might want to move them to other tickets as the current version is very close to being ready for staging.

[matej-vavrek]

@mwinokan all should be doable. I am doing some final touches.

[phraenquex]

@mwinokan and @phraenquex need to update the tooltip spec

[mwinokan]

@matej-vavrek thank you for your latest draft

Some feedback from @phraenquex and myself:

• [x] Please fix which tags are shown as bubbles in the observation window. It should only be curator tags (not generated XCA tags)
• [x] Please check the default width for both the hit navigator and observations panel, they could be smaller to minimise whitespace
• [x] The "show untagged hits" button in the tag details should only reveal hits that do not have any curator tags. (as every hit will have at least one generated tag)

Some bugs I found:

• [x] If a tag currently selected in the tag details window is 'hidden' using the 'edit tags' window, the page crashes. (This one might need @boriskovar-m2ms). An easy fix might be to deselect tags before hiding them.
• [x] Narrow hit navigator widths break the layout, please change the minimum width to fix this:

• [x] Please also check the tag details panel at narrow widths:

[mwinokan]

Summarising conversation w/ @matej-vavrek in slack:

• [x] Hiding a tag that is currently selected in the tag details panel should deselect the tag
• [x] The hit navigator and observation panel rows should still show generated tags even if they are hidden
• [x] Hidden curator tags should not be shown in the hit navigator and observations panel

[mwinokan]

Thank you @matej-vavrek for implementing the above! My hopefully final nitpicks are:

• [x] Some of the new components are not consistently aligned vertically (which looks a bit awkward):

• [x] Is it possible/easy to scale the text in each of the new generated tag boxes to use as much of the horizontal space as possible? I.e. can theA be a larger font size than the F1H? If this looks to messy it might be worth keeping the sizes consistent.

• [x] Please make the font style consistent between the pose name/compound and observation names

• [x] Is there a reason why the observation/pose short codes are always in ALL CAPS? In the download all the files/metadata uses the format Ax0152a vs AX0152A that is shown in fragalysis. Can we change the f/e to match the Ax0152a please.

[mwinokan]

Looking at @matej-vavrek's stack, there are a couple 'nice to have' things

• [x] The "Tag was automatically deselected..." warning appears even when a tag that was not selected is hidden
• [x] Please change the hover tooltip for the observations counter/button to be Show Observations

[phraenquex]

Probably not this ticket, but there's still a bug in the XCA-upload-display flow, because these tags should not all be identical:

This is the snapshot - though it's not redrawing properly - one for #1303, presumably already fixed.

[mwinokan]

Looking at the metadata.csv from CHIKV_Mac on staging:

• There is only one Crystalform in the dataset
• There is only one Quatassembly
• There are 14 different CrystalformSites
• There are 14 ConformerSites

Looking specifically at cx1125[a-d] there should be:

• 3 conformersites: 2a, 13a, 14a

• 3 Canonsites: 2, 13, 14

• 3 crystalformsites: F1a, F1b, F1c,

• 1 Quatassembly: A1

• 1 Crystalform: F1

@phraenquex This seems to be correctly captured in the F/E. So there could be a bug earlier in the pipeline (upload) but it seems consistent to me. I will check with Jasmin.

Snapshot

[phraenquex]

It's the crystalform sites that don't show up correctly in the observations pane.

For cx1134a: one observation (cx1134b) should be split into a new pose; but cx1134c should (surely!?) be from a different crystalform site. They can't both be from F1a.

I'm guessing the loader is picking the wrong field from the yaml.

@ConorFWild can you please work with @kaliif to pin this down.

(@mwinokan please break into a separate ticket if appropriate.)

[phraenquex]

For this ticket: we need some tricks (tooltips?) to make it quicker to work out why sites are assigned as they are.

@mwinokan @ConorFWild please come bug me so we pin down the spec - it could be quite trivial.

Probably (quick-n-dirty):

• tooltip on short code: long code
• tooltip on sites: sitetype: long site string

(@ConorFWild will need to point us to what's the relevant yaml field; @kaliif will have to ensure that it's loaded and served by API)

[kaliif]

It's the crystalform sites that don't show up correctly in the observations pane.

For cx1134a: one observation (cx1134b) should be split into a new pose; but cx1134c should (surely!?) be from a different crystalform site. They can't both be from F1a.

I'm guessing the loader is picking the wrong field from the yaml.

@ConorFWild can you please work with @kaliif to pin this down.

(@mwinokan please break into a separate ticket if appropriate.)

They're not from the same crystalformsite, but those sites have the same crystalform and the tag is generated crystalform name, rather than crystalform site, hence F1a for all three.

But if this is the spec for the tags, then it seems that crystalformsite tag scheme is wrong in the backend, the loader seems to be naming crystalformsites using crystalform data. Have you noticed this? Are the tags just wrong?

[phraenquex]

Thanks @kaliif for digging - yes, that tag should definitely be generated with the CrystalForm Site. So the bug is in the loader.

(We're talking about the middle (orange) one, right?)

I'm creating a this new ticket: #1466

[phraenquex]

Reposting comment above, to confirm that IS in scope for this ticket: https://github.com/m2ms/fragalysis-frontend/issues/1322#issuecomment-2177955732

[mwinokan]

@phraenquex says there are outstanding issues with the tooltips:

Currently the tooltips show the tag category which is important:

But we also need to communicate the 'long site string' from XCA:

e.g.: CrystalformSites - A71EV2A-x0450/A/201 - small cell <xtalform_sites.xtalform_site_id>

@matej-vavrek please change the tooltips for the new XCA colourful buttons/boxes to include not only the tag type but also the longer site_id from XCA

[phraenquex]

Bugs:

• [ ] If you change the main observation, the name of the pose doesn't update (in the LHS pane) @phraenquex to review spec.
• [ ] I turned cx0314b into a new pose, but that pose never showed up from the LHS (as far as I can tell).
• [X] "Select displayed hits" is broken, making it basically impossible to curate tags. (Maybe related to previous problem.) Fixed in #1419
• [ ] Compound id should be displayed for the observations, just like in the Hit pane for poses.
• [ ] Change "group" to "pose"
• [ ] Only observation checkboxes to be used with the pose/name buttons. (That would fix the weird name setting behaviour.)
• [ ] Funny jumping-around when setting the name. (This may also be a checkbox bug.)
• [ ] Auto-size the observations pane. Stretch as big as needed for all observations. Make it drag-resizable. (Add spec to #1417)
• [ ] Leave the LPC buttons visible, grey out if no selection boxes clicked.
• [ ] Draw heavy blue border around entire pose for which the observation is open. (Add spec to #1417 )
• [ ] Pose checkboxes should be detached from Observation checkboxes. (The former are for feeding into computations, the latter for curating poses - so different use cases. We may discover this is restrictive, but we'll worry about that later.)
• [ ] Need select all button in observations pane
• [ ] Need select all displayed button in obs pane.
• [ ] Open the new observations pane immediately when clicking on a different pose. (Currently closes it.)
• [ ] Multi-row tooltip, like this (ish):
• [ ] Tooltips: always singular (site not sites)
• [ ] For poses: make pose name bold, make compound name non-bold one point smaller, slightly greyer.
• [ ] For observations: make the main observation bolder. (And copy the compound name font etc from pose.)

@matej-vavrek please create new tickets as relevant, else move this back to "In progress."

(The hit navigation selection tools need a serious spec overhaul - @mwinokan a high priority for when you're back.)

[mwinokan]

@matej-vavrek please let us know which of the above are difficult. @phraenquex to help identify which ones are blockers for green

[matej-vavrek]

@phraenquex , @mwinokan , from the top of my head:

Need to investigate (and time):

• [x] If you change the main observation, the name of the pose doesn't update (in the LHS pane) @phraenquex to review spec.
• [x] I turned cx0314b into a new pose, but that pose never showed up from the LHS (as far as I can tell).
• [x] Only observation checkboxes to be used with the pose/name buttons. (That would fix the weird name setting behaviour.) [M: maybe auto-deselect selected observations on observation modal close could help/solve this]
• [ ] Pose checkboxes should be detached from Observation checkboxes. (The former are for feeding into computations, the latter for curating poses - so different use cases. We may discover this is restrictive, but we'll worry about that later.) [M: this is probably only a visual indication]
• [x] Funny jumping-around when setting the name. (This may also be a checkbox bug.) [M: this should not be a problem anymore as setting the pose name was removed in #1475]

Should be alright:

• [x] Compound id should be displayed for the observations, just like in the Hit pane for poses.
• [x] Change "group" to "pose"
• [x] Leave the LPC buttons visible, grey out if no selection boxes clicked.
• [x] Open the new observations pane immediately when clicking on a different pose. (Currently closes it.)
• [x] For poses: make pose name bold, make compound name non-bold one point smaller, slightly greyer.
• [x] For observations: make the main observation bolder. (And copy the compound name font etc from pose.)

More time consuming:

• [x] Draw heavy blue border around entire pose for which the observation is open. (Add spec to #1417 ) [M: this could be also alright]
• [x] Auto-size the observations pane. Stretch as big as needed for all observations. Make it drag-resizable. (Add spec to #1417) [M: was this only for height?]
• [x] Need select all button in observations pane
• [x] Need select all displayed button in obs pane.
• [x] Multi-row tooltip, like this (ish):

Backend related:

• [x] Tooltips: always singular (site not sites) [M: we are getting tag categories names in plural from backend API]

[matej-vavrek]

@phraenquex, @mwinokan, I have updated my stack with checked points from my comment. Could you have a look, please? There is also experimental "auto-deselect selected observations on observation modal close" but it is not and will not be a proper solution after discussion with Boris, please ignore this behaviour.

[mwinokan]

Thanks @matej-vavrek, most of it looks great. A couple notes:

• [x] I am unable to select multiple observations, when I select a second one the first is deselected
• [x] The lack of spacing between the observations modal and new dark-blue border is bothering me slightly, and if it's easy please remove the white padding between the existing hit navigator row border and the new dark-blue one:

Also, you were asking about being able to resize the observations modal, for #1476 we will need a wider modal anyway, I suggest increasing the size of the highlighted part below when the modal becomes wider:

[matej-vavrek]

Thank you @mwinokan for the feedback. I have updated my stack with fix. I am still not 100% sure if the border and spacing with modal is sufficient.

[mwinokan]

@matej-vavrek says auto-sizing only the height is easier, @phraenquex says that's fine. Width resizing can be revisited with combi-soaks #1476

@phraenquex also clarifies that for the pose and observation checkboxes separation is needed. This should be spun out into a new ticket and also discussed with @boriskovar-m2ms

[matej-vavrek]

I am unable update my stack today. @phraenquex , @mwinokan, should the multi-row tooltip looks something like this? It shows on XCA tags hover.

[phraenquex]

Thanks @matej-vavrek - as ever, a mockup helps so much! Now I see how I mis-speced: it actually needs to be a table.

So in each case, the bit after the dash is what needs to go into each cell. (The short codes are already displayed in the coloured boxes.)

Auto-size the columns (and overall width?) so they never wrap (unless of course the tooltip ends up wider than the browser window).

[mwinokan]

@phraenquex can I suggest the table is in long format rather than wide? I think that would help reduce it's width:	Type	Value
CanonSite	A71EV2A-x0211/A/120/A
ConformerSite	A71EV2A-x486
CrystalformSite	A71EV2A-x0486/A/147
CrystalForm	A712A_open
QuatAssembly	monomer