Resizing of the staging area / code area / guide

[HarmaZha]

What's the problem?

The goal is to allow users to resize the screen to the size they want so the view of their workspace will be unobstructive and they are able to see exactly what they want to see (similar to how in VSCode we are able to drag the terminal / file explorer / coding area to the size the user wants).

What's the design idea?

I would address this problem by adding interactivity to the sides of each "tile" and making it so those sides act as sliders. This will allow for the views to change.

Who benefits?

Especially for people with smaller computer screens, it is difficult for a user to look at everything they want. This way the lay out of the page will be precisely what the user wants it to be. However, having all of this interaction on the screen might cause more confusion for the user, they might resize the the screen when they did not mean to.

Design specification

The interface already has distinct sections, but we'll add borders of interactive sliders for resizing. These sliders will provide visual feedback and allow users to click and drag to adjust section size within a set min and max limit.

Our current free layout allows users to adjust tile borders, offering some customization. However, we propose a new interaction. This will enable users to drag the bottom border of workspace sections to resize, independent of the existing layout options. This new interaction will allow for the direct resizing of entire sections. it will not alter or affect the current free layout's functionality. Instead, it serves as an additional, standalone option for users wanting more control over their workspace layout.

We're introducing minimum and maximum limits to ensure that adjustments made to one section of the workspace are both flexible and controlled. Set at 75px, the minimum limit ensures that every section remains visible and functional, regardless of how much resizing is done. This limit will maintain the usability of each workspace, even on the smallest screens. The maximum limit is 75 pixels short of the total screen size. This ensures that no section can be expanded to the point where it compromises the visibility or usability of sections. By setting this limit relative to the screen size, we will ensure that the workspace has fluidity across different screen dimensions.

There will be a button slider/dragger that is similar to one in VSCode, for example. This will allow users to slide the tiles to their liking. As users manipulate a tile, the interface will offer immediate visual feedback. This will include the adjustment of adjacent tiles, ensuring that the overall workspace remains coherent and balanced by the users total screen size. Regardless of the initial screen size, when a user adjusts one tile, the system redistributes available space among all tiles.

[amyjko]

Thanks for reporting @HarmaZha! I think there are reasonable interaction designs for this; let's hope someone grabs this and comes up with a good design for it. Note: whoever does, this needs to be keyboard accessible, in addition to mouse accessible, so drag only designs are not sufficient.

[kmutzet]

@amyjko not sure if this is the way to tag you, but if you could review this design spec that would be amazing! default layouts for certain sizes can help the overall appearance on smaller screens, and then adding certain controls to customize it more would be great! An example this is inspired by is React (Bootstrap) Card container, something that resizes with the window (and if the window gets small enough you can change the whole layout if need be).

[amyjko]

Thanks @kmutzet! Yes, this is how you tag people on GitHub. Comments!

• Thanks for the initial design sketch! Because this is an inherently visual design issue, you'll need to include visual sketches of the design you're proposing, so there's no ambiguity about what you're proposing to build.
• How does this align with the existing behavior of the "free" layout, which supports dragging borders of tiles? Is it the same interaction, just applied to the automatic layouts, or are you proposing a different interaction? (We generally follow a consistency principle here, so deviating from existing interaction designs needs a good reason).
• What are the min and max limits you're proposing? How do they interact with the fact that moving one boundary of one tile will change the size of another? (Most conventional tiled window interfaces don't use a concept of a min/max, they use a concept of a "split" percentage, distributed between two halves).
• It's not clear in your design what undo/redo are doing. Those are already bound to project edits. What are you proposing to undo or redo?
• What does "consistent aesthetic" mean? We'll need some explicit mockups to know what you're proposing.

Thanks!

[tammyn17]

How does this align with the existing behavior of the "free" layout, which supports dragging borders of tiles? Is it the same interaction, just applied to the automatic layouts, or are you proposing a different interaction? (We generally follow a consistency principle here, so deviating from existing interaction designs needs a good reason). Users can drag the bottom border of sections to resize. It will be in a new design but extends to automatic layouts. This will give familiarity with the current system now and hopefully avoid confusion. Stage has full screen mode and one of the sections is collapsible, however there are no sliders/dragging features to minimize and expand workspace sections easily. Overall we need new design/interactions because if the screen is sized down (lets say to mobile size/dimensions) there should be default layouts in place for if the screen gets that small, to make it appear cleaner. We need 2 things: adjustments to section sizes and then more default layouts for different screen sizes.

What are the min and max limits you're proposing? How do they interact with the fact that moving one boundary of one tile will change the size of another? (Most conventional tiled window interfaces don't use a concept of a min/max, they use a concept of a "split" percentage, distributed between two halves). The idea is to introduce a flexible but controlled resizing capability. With split percentage, we feel that users might be able to almost fully get rid of a needed workspace. The minimum limit ensures that every section remains usable and visible, while the maximum limit prevents any single section from overwhelming the workspace. When one boundary is moved, the adjacent section's size adjusts accordingly, within the defined min/max constraints, ensuring a balanced distribution of space. So this should work for as small as mobile screen sizes to large computer screen sizes.

It's not clear in your design what undo/redo are doing. Those are already bound to project edits. What are you proposing to undo or redo? We are proposing to add another function to undo and redo, so that when you zoom in or resize the screen, clicking the undo button should undo those screen size changes. This can make a quick fix option for users who accidentally zoom in too much or size the screen in a way that doesn’t make sense to them.

What does "consistent aesthetic" mean? We'll need some explicit mockups to know what you're proposing. When we say ‘consistent aesthetic’ we mean that when the person resizes the screen, it shouldn’t really cause that big of a change to the initial layout we have in place. So resizing should make small adjustments (smaller screen friendly layouts), not changing the layout of the screen that much.

@amyjko

[amyjko]

@tammyn17 Just documenting that we chatted in person about this. A few decisions that came out of that chat:

• Move the design proposal to the issue body, not a comment
• Remember to explain what you're asking for when you tag someone, rather than making them guess
• Preserve formatting when you paste content from elsewhere
• There were a few issues in the proposal that seemed out of scope for this issue, and should be new issues.

[tammyn17]

@amyjko Kate and I just did a new proposal, if you can read it over and let us know what you think. We are also working on making the other issues into new issues, so the proposal sounds a bit short now. I wasn't completely sure how to make the visual, so I tried to make the paragraph more detailed.

[amyjko]

@tammyn17 The overall design looks good to me; it follows conventions well. My only remaining question is keyboard accessibility: this can't be a mouse only interaction. How would someone with a keyboard modify the split between tiles? The convention is usually to have a button, which is focusable, but then there's the question of what keyboard actions would cause readjustment. For example, would there be separate left/right up/down buttons and activating them moves it by some increment? Or would it be arrow keys? What would be WCAG 2.2 compliant?

[amyjko]

It's the end of Winter! Please provide an update on this issue, including:

• Whether you plan to continue work on it
• If you do not, 1) provide a detailed update of its status, 2) add any unfinished work, 3) list any any unmerged branches, and 4) unassign yourself, so someone else can take over the task. Please leave the issue in better shape than you found it, helping future contributors to start from where you left off.

If you do plan to continue work on it, carry on. Otherwise, thank you for your contributions!

[amyjko]

No reply :( Unassigning @tammyn17 @kmutzet.

[cdong03]

@EnclaveGeneral and I want to try working on this issue.

[amyjko]

Let me know how I can help. I don't see @EnclaveGeneral in the teams yet; make sure they're added to this issue as soon as they are invited.

[cdong03]

I don't see a button to assign people to the issue, so I don't think I can assign him. Can you please assign him to the issue?

Sincerely, Caroline Dong

On Thu, Apr 11, 2024 at 7:04 AM Amy J. Ko @.***> wrote:

Let me know how I can help. I don't see @EnclaveGeneral https://urldefense.com/v3/__https://github.com/EnclaveGeneral__;!!K-Hz7m0Vt54!lLRiHVbaYN94dXX-FHdaf7QPt7twiYh8qJWf_h7PuahYCorzgxrv7BLxVUcD-hQcUuORcOzw4iW_tarZzFM3Jg1O$ in the teams yet; make sure they're added to this issue as soon as they are invited.

— Reply to this email directly, view it on GitHub https://urldefense.com/v3/__https://github.com/wordplaydev/wordplay/issues/370*issuecomment-2049770720__;Iw!!K-Hz7m0Vt54!lLRiHVbaYN94dXX-FHdaf7QPt7twiYh8qJWf_h7PuahYCorzgxrv7BLxVUcD-hQcUuORcOzw4iW_tarZzAhwbr6K$, or unsubscribe https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AV3A6JAXF32U6E3QBVK6BTTY42J77AVCNFSM6AAAAABCUCO6TCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBZG43TANZSGA__;!!K-Hz7m0Vt54!lLRiHVbaYN94dXX-FHdaf7QPt7twiYh8qJWf_h7PuahYCorzgxrv7BLxVUcD-hQcUuORcOzw4iW_tarZzFewaeSN$ . You are receiving this because you were assigned.Message ID: @.***>

[amyjko]

Assigned.

[cdong03]

I made a commit to the branch for resizing the tutorial dialog view. I made the border between the dialog/stage 4px wide. It's not perfect because I hardcoded the initial dialog width. I haven't implemented resizing the project/play views yet. I want to know if the current state is acceptable first. Commit: https://github.com/wordplaydev/wordplay/commit/2ea228c7b0be677732a641d87459232cc15fd884

[amyjko]

Hi @cdong03! First, a process note: the best way to get feedback on a draft fix is to submit a draft pull request. Pull requests are designed for that explicit purpose, to have someone review a proposed change. Start one of those to request feedback in the future on partial fixes.

Re: the design

• The basic functionality is solid, and meets the requirements in the design spec. Nice work!
• The visual design is inconsistent with the visual language established in the rest of the site. There's probably some need to make it clear that it's draggable, but it should be using the predefined colors and widths defined in global CSS variables, not hard coded one-off sizes and colors.
• Hard coding initial width is fine, but it should be something sensible. The prior default was 30% of the page, but a better default might be something like 20ems, to default to a legible line of text.
• This issue never mentioned anything about the tutorial dialog; it's about the project view, and the ability to resize the automatic layout of tiled windows. We can expand the scope to include the tutorial view too, but that really is a different issue.

[cdong03]

We submitted a pull request for this issue, but it may not be complete. I won't be working on it in the future. Here is a summary of what is implemented and what hasn't been.

We implemented resizing the project tiles by dragging with a mouse. This resizing is based on setting the styles directly instead of changing the layout object. When I tried changing the layout object, even inside handlePointerUp(), resizing stopped working.

Implemented:

• Resizing tiles with mouse, including tutorial dialogue and project tiles (guide/palette/stage/etc).
• When resizing corners, adjacent tiles resize as well. This means when 4 tiles are next to each other, they can be resized diagonally

Notes:

• There is resizing lag that's more apparent on some computers than others
• Keyboard accessibility not implemented (resizing with key presses)

[amyjko]

@cdong03 Can you clarify whether you'll be finishing the pull request? It sounds like you're abandoning it, and not finishing it?

[cdong03]

@amyjko What does it mean to finish the pull request? I think I have completed the resizing functionality and have decided not to work on it further (for example, adding keyboard accessibility). Is there more I have to do with the pull request?

[amyjko]

A pull request is done when there's no more feedback to resolve and the commits have been merged into main. If you're ready for feedback, you should say so; if you're not going to work on this any more, you should say so, so that I know that I have to finish it myself, or delegate it to someone else. We make all of this process clear in the development wiki, where we explain the pull request process. You should be referring to that when you're unsure about process.

Can you please clarify your status? Are you a) ready for feedback and will finish this or b) will not be finishing this and expect someone else to? Thanks!

[cdong03]

@amyjko I see, thanks. I won't be working on this issue anymore.

[amyjko]

Alright. I will finish this issue and pull request then, unless another volunteer commits to finishing it. Thank you for contributing initial progress on the feature.