(fix) Workspace window should have the size of the preferred window state #1444
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Size Change: -99 B (0%) Total Size: 10.5 MB ℹ️ View Unchanged
|
|
@cduffy2 @paulsonder I'd appreciate your insight into a question regarding this PR: Should the workspace size change to the default size for the tab when switching between workspaces? These changes make it such that when I open or re-open a workspace, it is automatically set to its default size. @vasharma05 I'm not sure if we should treat the workspace as a single object or a per-app object. In the former case, I'm inclined to say that the workspace should not resize when switching between already opened workspaces, though it may be appropriate to resize when a new workspace is open. In the latter case, we should add some state tracking the current status of each workspace so that when the view is restored, it reverts to whatever size it was displayed at previously (that is, if I was working on entering vitals, maximized that, switched to the order basket and then switched back to the vitals, I'd expect the vitals app to be displayed at the maximized size I had it at previously). |
ibacher
reviewed
Nov 1, 2023
|
@vasharma05, @ibacher Generally, we want to give the user control. I'm not sure why the order basket here is displayed full-screen, it wasn't designed that way. For a clinical form, there is a toggle that allows the user to toggle between 520px and full screen. The other side panel items (basket and visit note) should be 420px. I don't believe either of those items have the full screen toggle option. Does that clear it up or am I missing something on what this PR is trying to achieve? Thanks |
This was just for demonstration purposes of the feature. The order basket will remain displayed at the normal size. What this PR is trying to achieve (I think) is ensuring that the workspace opens in the correct size for that workspace, so 520px for the form, 420px for the others or, if we have a workspace designed to open full screen, full screen. However, as implemented it goes something like this:
So, I the UX question I have here are:
I hope that's clear enough! |
|
Thanks, bit clearer now! So I guess you need to answer these questions so that you can define the logic / behaviour in code, in case it comes up in the future. even though we don't yet have a second side rail item to be full screen. Is that right? To your questions,
I think full-screen.
Based on 1, I think when you switch to the second workspace, it would already be full screen. Because you've already set the previous one to be full screen, so presumably you are in a mode of work whereby you don't want to see the chart. If we had this feature though, the workspace controls might need a small revision to make clear visually when you're toggling the size it applies to anything you open in the side rail. We don't have scope to do that at the moment, so my hope is that the reason this is being implemented now is more about the code being robust? Does that make sense? |
|
Nice work. Learned alot on this PR |
|
Thank you @ibacher and @duffman7 for clear paths to move forward with. Since @ibacher pointed this out that the workspace should not be on per-app basis, I totally agree with this, which is also supported by @duffman7's comments. One more scenario comes up here, let's say a particular form is meant to be in full screen(form has the clinical-form variant), when I open the form, it opens in the full screen. Now, if I go ahead to open notes form, please note that the notes form (variant: siderail variant) doesn't have the option to maximize, will the notes form still open in the full screen or not? Please refer to various workspace variants here |
|
Hi @ibacher @duffman7, how should we move ahead with this PR? |
Based on @duffman7's comments above, I think it still opens in the full screen mode. I think the idea that workspaces can either have full screen "enabled" or not is probably a distinction we should do away with. |
|
I just had a chat with @duffman7 regarding the final solution to the full-screen workspace. He suggests that we should only allow opening the clinical forms in full screen if the implementation wants it ( |
|
Thanks Vineet. And to add, the rationale for this is a) to give the user
control so they can easily toggle the clinical forms screen into
fullscreen, or half-screen as preferred and b) for the other side rail
items, there have been no requests from implementations for the visit note
or order basket to be full-screen, so let's keep things simple and only
have one format for those forms.
…On Tue, 5 Dec 2023 at 10:41, Vineet Sharma ***@***.***> wrote:
I just had a chat with @duffman7 <https://github.com/duffman7> regarding
the final solution to the full-screen workspace. He suggests that we should
only allow opening the clinical forms in full screen, if the implementation
wants it (preferredWindowSize = maximize) and when we switch from the
clinical forms to another workspace, say the notes workspace, the other
workspaces should be opened in the normal size (320px) only.
CC: @ibacher <https://github.com/ibacher> @denniskigen
<https://github.com/denniskigen>
—
Reply to this email directly, view it on GitHub
<#1444 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACWAU2EV5RAQZG3PQHCPHKLYH3T5HAVCNFSM6AAAAAA6XIK6R2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBQGM4DSNRQHA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
*Ciarán Duffy*
Independent Designer
+49 152 28458104
duff.work <http://www.duff.work/>
He / Him / His
|
|
@duffman7 That all makes sense.
I'll just throw in some context here: we allow the default visit note to be swapped for an actual form. In the concrete implementations I've seen, the default visit note is swapped out for a form or simply removed altogether. Likewise, the order basket is not yet in a state where it's being used in production. So the lack of requests may be more related to the lack of actual use of the feature. |
ibacher
approved these changes
Dec 5, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Requirements
Summary
This PR fixes the issue that the workspaces with preferredWindowSize =
maximizedwas also opening innormalway.The PR includes:
Screenshots
P.S. The order basket's preferredWindowSize =
maximizedfor demo purposes.Screen.Recording.2023-10-31.at.13.40.32.mov
Related Issue
None
Other
None