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

[matej-vavrek]

Current proposal (header row omitted after discussion with @mwinokan ):

[phraenquex]

No it needs to be wide:

• must must have the same orientation as the coloured boxes.
• for when there are many observations. (The tooltip must show the strings for all observations in the pose.)

(It might be helpful to have a a vertically aligned single-observation tooltip when you hover somewhere (observation string?) - or it might be confusing.)

The CrystalFormSite needs to have the bit before th hyphen chopped off.

[mwinokan]

@matej-vavrek is working on the wide-format table

[matej-vavrek]

@phraenquex, @mwinokan, could it be something like this?

Or maybe try another colour for individual observations?

[mwinokan]

Thanks @matej-vavrek, I think the second one (without the overlap) looks good, but what if there is a large number of observations?

[matej-vavrek]

It is the same variant, but different observation 😅 If we do not want the overlap then we can maybe put it on top of the table?

[mwinokan]

@matej-vavrek ah I see. In that case could you maybe just highlight the row that is currently being hovered over? Either way I think the single wide table will be enough

[phraenquex]

@matej-vavrek - what does it look like with only the table? I'm still pretty sure that'll be my preference - too much tooltip-ping gets confusing.

[matej-vavrek]

@phraenquex, only the table

With possible row highlighting - when you hover over an observation its row highlights

[phraenquex]

@matej-vavrek let's go with only-table for now, then. (We can review later.)

Leave out the highlight; here's a better solution: align the table rows horizontally with the observations in the panel. (That way the eye can easily work out what is what.)

(Btw, this has immediately made it clear there's a bug in the loader, it's clearly pulling the wrong strings from metadata.yaml. We'll have to discuss tomorrow with Tim if there's absolutely no way to get this fixed before Kalev is back.)

[matej-vavrek]

@phraenquex hmm and should the alignment also be a "scroll" responsive? If there will be more observations and so scrollbar in their modal, if tooltip should also "scroll" or mirror observations rows.

[phraenquex]

Yes, ideally: as you scroll the observations, scroll the table. (Is that easy to do?)

The table itself doesn't need a scroll-bar.

Also, if it's easy: make the text in the tooltip selectable for copy-paste.

[matej-vavrek]

@phraenquex, I think that in this case it could be easier and probably more practical if we "adapt" on hover behaviour on observations modal - remove tooltip table and just simply extend tag names in color boxes when the mouse is over the observation modal? Because tooltip is not selectable from its own nature and we are basically extending rows with already existing informations but in separate table. What do you think?

[phraenquex]

Yes you're right. So put an active strip to the right, with a pop-out arrow (ilke on google maps).

[phraenquex]

(If it's easy to do: make it a pin, so that the pop-out happens (or doesn't) when you open the observation pane.)

[matej-vavrek]

(If it's easy to do: make it a pin, so that the pop-out happens (or doesn't) when you open the observation pane.)

I am not sure if I understand this correctly @phraenquex - instead of a pop-out arrow there will be a pop-out checkbox (or pin like icon?) and when this will be checked/set, then the Observations dialog will be shown in extended version and when it is not the it will be like it is now? So the state will be preserved and not lost on close/open?

[phraenquex]

@matej-vavrek yes correct. Or better: have both the arrow and the pin icon below one another: arrow just pops open the extension; the pin pops it out and keeps it out.

But very important: only do the pin if it's easy to do!!! If not, put it into a separate ticket, and we can review later if it's required.

[matej-vavrek]

@phraenquex it should not be difficult but it will take some time to implement. I would prefer creating a new ticket so this one can be finished and merged.

Changes are on my stack, including copy button from #1465

[phraenquex]

@matej-vavrek when will the fix we discussed yesterday be visible/testable?

[matej-vavrek]

@phraenquex at the end of today or tomorrow morning

[matej-vavrek]

@phraenquex, I updated my stack. Is this going the right direction, please? Currently, there is a problem with an column alignment and "header" in expanded window, because additional columns in each row are basically as separate parts..

[matej-vavrek]

@phraenquex, I have fixed position of the button and also overlaying layout. I can merge it if it is fine now.

[phraenquex]

@matej-vavrek that's perfect!! Please merge it into staging ASAP - I need it to finalise spec for #1482 (green).

[matej-vavrek]

@phraenquex, it should be merged in staging now and I have also updated my stack with our latest stagingcandidate.

[mwinokan]

@phraenquex raises the issue that it is difficult to find the original crystallographic data from the f/e UI.

@matej-vavrek please add the observation long code to make it easier to trace.

[matej-vavrek]

@phraenquex, @mwinokan, I have updated my stack - added long code column and updated sorting for tags in "Tag Details".

Expanded observations dialog is getting quite wide now and I was thinking if in the long code column should not be just a copy button instead of the long string and the string put to the button's tooltip. What do you think?

Sorting in "Tag details" is same as in edit tags dialog so it sorts by category first and then by name. Reverse sorting reverts only name sorting and categories are sorted the same. Is this behaviour alright or should it do in other way..?

[mwinokan]

Thanks @matej-vavrek, the new long code field and sorting looks good to me. Please push to staging.

The text in the fields will get shorter (#1496) so I don't think you need to make changes.