(feat) O3-3253: Move the details panel button below the Patient Header in the workspace

[usamaidrsk]

Requirements

• This PR has a title that briefly describes the work done including the ticket number. If there is a ticket, make sure your PR title includes a conventional commit label. See existing PR titles for inspiration.
• My work conforms to the OpenMRS 3.0 Styleguide and design documentation.
• My work includes tests or is validated by existing tests.

Summary

This PR moves the show details button below the patient details.

Screenshots

show-hide-details-below-patient-details.mp4

Related Issue

O3-3253

Other

[mogoodrich]

@usamaidrsk can we have a screenshot of how this would look when used as the patient banner on the patient chart, and also with the actions button present.

[denniskigen]

@ibacher is this the implementation you envisaged? I've messaged Paul and Grace on #ux-design-advisory to get their thoughts on the redesign.

[ibacher]

I would've anticipated only moving the button in the condensed version of the patient banner. I.e., in the chart, this actually makes the banner take up more visual space, which seems undesirable.

[denniskigen]

I agree. Is there a contextual prop @usamaidrsk should be checking for to know whether the banner is the condensed version?

[ibacher]

patientBannerRef.current.scrollWidth maybe? If it's <= 500px it should be being rendered in the workspace (we need to talk to Paul or Ciarán about the workspace size... It looks like we're mostly using the wide version everywhere?).

We might also want to make that dependent on the isTabletViewport state variable, so that it changes if the window resizes into tablet mode.

[denniskigen]

It looks like we could also conditionally render based on isTabletViewport which is computed from ResizeObserver. Gives you this:

isTabletViewport.mp4

[usamaidrsk]

It looks like we could also conditionally render based on isTabletViewport which is computed from ResizeObserver. Gives you this:

Yes, @denniskigen that does do the trick.

[ibacher]

So, I was expecting the condition here to be something like:

const renderDetailsButtonBelow = !isTabletViewport && (!Boolean(patientBannerRef.current) || patientBannerRef.current.scrollWidth <= 500);

Basically:

1. We do not want to move the details button in tablet mode, because tablet mode is actually wider than the workspace, so this should be a non-issue. (We may want to move it in tablet mode when there are less than maybe 800px of screen width, but let's consider that if / when it comes up or we have more concrete design guidance).
2. We only want to move the icon if the <header /> element is 500px or less, because that indicates that we're being rendered in the workspace (tablet mode is a minimum of 600px of screen real-estate).
3. If the ref has not yet been set, we don't know which of these two modes to use, so we just assume the default (render to the right).

[mogoodrich]

Defer to @ibacher on this....

[ibacher]

This is the technical version of "we leave the patient banner as-is, but where there’s 500px or less of width to render the banner in, we move the “Show Details“ to a new line" 😁

[usamaidrsk]

I have pushed an update that uses

const renderDetailsButtonBelow = patientBannerRef.current?.scrollWidth <= 520;

As per zeroheight workspace documentation.

On desktop screens, the workspace sits on the right side of the page. Its width is 420px in most cases, and 520px if it's a clinical form.

[denniskigen]

Suggested change

	const renderDetailsButtonBelow = patientBannerRef.current?.scrollWidth <= 520;
	const maxWorkspaceWidth = 520;
	const showDetailsButtonBelowHeader = !isTabletViewport && (!Boolean(patientBannerRef.current) || patientBannerRef.current.scrollWidth <= maxWorkspaceWidth);

The current logic doesn't account for two of the situations Ian mentioned above.

[usamaidrsk]

Yes @denniskigen. Thanks for pointing this out. I tested it with the condition provided, but the appearance on the desktop view was not as expected.

Therefore, I decided to only check the width of the banner instead. Whenever the width is less than 520px, the button will be displayed below the header. This way, the button will never appear under the header on tablets, as they are greater than 520px in width.

cc @ibacher

[denniskigen]

So I've just tested this and it works well with workspaces:

show-details-button-below-patient-header.mp4

It doesn't work as well with overlays (such as what we use for the Appointments form). Is it because we don't constrain the max-width @brandones @mogoodrich? Perhaps setting a max-width and using that value for the condition could be the ideal approach:

[usamaidrsk]

Thanks @denniskigen!,

It doesn't work as well with overlays (such as what we use for the Appointments form). Is it because we don't constrain the max-width

I think the screenshot looks okay, given that the patient details on the banner are not compressed/squeezed as to why @mogoodrich suggested to improve the layout.

[denniskigen]

Ok. Approving and deferring to @mogoodrich to merge if it meets the acceptance criteria. Thanks, @usamaidrsk!