Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Task area is not responsive for Survey tasks #5093

Closed
seanmiller26 opened this issue Aug 1, 2023 · 3 comments · Fixed by #6297
Closed

Task area is not responsive for Survey tasks #5093

seanmiller26 opened this issue Aug 1, 2023 · 3 comments · Fixed by #6297
Assignees
Labels
bug Something isn't working degraded-ux UX is degraded

Comments

@seanmiller26
Copy link
Contributor

Package

Describe the bug

When reducing the browser window the subject continues to get smaller but the task area does not, taking up the same amount of space. This makes the subject area unusable, blocking many elements on the screen.

Screen Shot 2023-08-01 at 10 40 30 AM

To Reproduce

Steps to reproduce the behavior:

  1. Go to Snapshot Serengeti
  2. Shrink your browser width to just above 768
  3. See unusable subject area

Applicable Panoptes resource IDs (project, workflow, etc) to demonstrate the issue:

Expected behavior

Similar to other FEM task areas, which shrink alongside the subject area:

Screen Shot 2023-08-01 at 10 41 50 AM

Device information

Desktop:

  • Browser: Chrome

Additional context

Add any other context about the problem here.

@seanmiller26 seanmiller26 added bug Something isn't working degraded-ux UX is degraded labels Aug 1, 2023
@Saicbmm
Copy link

Saicbmm commented Dec 28, 2023

For the Snapshot Serengeti bug, it appears that there are already zooming features available for the subject (represented as magnifying glasses) and they do just fine. You shouldn't have to shrink your browser width if you want to zoom in on the subject. However, I do believe that the subject should still be properly visible since users can also use the keyboard shortcut to zoom in/out. My suggestion is that when the user zooms in using the keyboard shortcut, the length of the image size shouldn't go beyond 80% visibility. A control flow program should be given with a decision to use keyboard shortcut or the given UI feature, but not both. In other words, top priority while coding should be given for image visibility.

@mcbouslog mcbouslog self-assigned this Aug 27, 2024
@mcbouslog
Copy link
Contributor

mcbouslog commented Sep 5, 2024

@seanmiller26 - adding word-break: normal; overflow-wrap: anywhere; creates the following:
SnapshotSafariscreenshot

Is this preferable, addresses this issue?

Reference for when this is revisited - https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_text/Wrapping_breaking_text .

@seanmiller26
Copy link
Contributor Author

I think we should hold off on this issue and address #6237 and #6238 first. Let's unify the styling and then we can go from there.

If we have time I'd be happy to talk further about breakpoints. I think there's a lot of options we can explore, but the above isn't the ideal solution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working degraded-ux UX is degraded
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants