Move zoom out into PreviewDropdown #58202
Conversation
richtabor
added
[Type] Enhancement
|
Size Change: -1.55 kB (0%) Total Size: 1.74 MB
ℹ️ View Unchanged
|
|
Flaky tests detected in ae35378. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/7642552449
|
|
Oh, nice one, that's interesting! Here's a GIF of what I observe:
Specifically I click in that GIF the preview dropdown, where a 50% zoom exists, which I then toggle on to zoom out, and off, to zoom back in. This is a little different from what you note in the post, maybe I had some errors in compiling the branch, let me know, but if we do move the controls in here, I'd have both 100% and 50% zoom, so one is always checked. One curiosity is that the zoom out in this branch is mutually exclusive with the Desktop/Tablet/Mobile previews. That's actually what gives me a little pause here, if the zoom control is meant to be explicit, something user invokeable, and live there, then either it should be one dropdown group so it's clear that they are mutually exclusive, or they should stack, i.e. I can see Tablet at 50%. The latter isn't that useful, but the former is a bit confusing. If we do want user control of zoom levels, another option is to add a control in the breadcrumb footer bar, a tiny stepped slider, or just a dropdown that shows Another option is to tie it to an edit mode. It isn't clear how useful this is when you're just writing a post or page building, but when you're building with sections, inserting top-level patterns, it's very useful. I think I've seen separate mockups (from you?) where this mode gets automatically invoked when you press the pattern tab in the inserter, changig the editing mode of the canvas to reveal top-level sibling inserters for pattern placement. That feels like a fluid way to invoke the zoom contextually; does the user need more zoom level control here? |
|
@jasmussen I pushed up changes to make zoom stack with device previews, like this: zoomout-2.mp4What do you think? |
Yes, I think we'll invoke the zoom-out mode in areas where it makes sense to do, like how it's done in when previewing styles. But I do think it's a nice-to-have to zoom out and see a whole page's design. We do it in Figma all the time, to take a birds-eye view and make sure elements are cohesive, aligned properly, etc. I do like having it in the existing device preview control—even stacked with preview. It's a relative control and feels expected. |
|
I think it might work, when stacked. Not entirely sure how useful it is, but if it can directly tie into any how the style variation zooming and any future assembler or site-view related zooming might work (same componentry etc), then it might be okay? I think my main concern is putting it in that dropdown. I still have this idea that the preview dropdown can potentially hold extensibility for plugins there, such as "view with paywall" or "view with premium" or other things. Those might still all stack, but it could also become a long list. Maybe that shouldn't block this, but pertinent for the thought process perhaps. |
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
Made some changes based on feedback:
Thoughts @WordPress/gutenberg-design @mtias? zoom-3.mp4 |
|
We do need to omit this from the post editor, or add zooming there (which I presume is a bigger lift). |
getdave
force-pushed
the
try/move-zoom-out
branch
from
80b6d7c
to
9310ed9
Compare
|
This looks good @richtabor Rich! What about just clicking twice on the 50% zoom? EDIT: The reason why I say this is that we have for instance List View. Click once to open and click again to close. The same goes for other things that can be pressed. Once to activate/open and once to deactivate/close. |
|
Let's not merge this quite yet, there are some aspects around the zoom out experiment that I think we need to figure out in a more holistic way. This PR can be part of that, but let's hold off on merging until the view is clearer. |
|
@jasmussen I'm not really sure why we should hold this PR. It feels like an improvement to me over the weird button we have in trunk. It's still an experiment though but it makes the current experiment a bit better. |
I'm curious - why we can't merge this as it's under an experiment? We don't know the full scope of the project but that would seem ok in this context. Can you help me to understand? Thanks. |
|
Oh I thought it took it out of the experiment. If it remains as an experiment, that's seems okay. My personal concern is that we are adding both granularity and promincence to a tool that I'm not personally sure will be that useful in practice. The existing experiment let us test a generally zoomed out view, but in practice it hasn't felt that useful. I always saw the evolution to be less promince and less granularity by being invoked by doing another action, such as opening the Patterns section, or invoking a "receded view" through another action. I.e. it could be tied to select mode. But never anything explicit like it is in Google Docs or otherwise. Just zooming out, as a separate affordance, just feels like another tool that doesn't have a clear utility. |
Test ReportThis report validates that the PR addresses the issue.Patch tested: #58202, Environment
Actual results
|
|
@jasmussen ah yes it's still an experiment. Perhaps @richtabor is best placed to advise on the utility of the PR but I'm still inclined to merge it and iterate within the context of the experiment. |
|
we actually discussed some of this with @mtias and it seems that we might want both:
|
|
Just quick feedback that I think conflating both zooming in/out on your content with a preview of what the content looks like on different devices is quite confusing. I don't think they are the same mental models at all. For zoomed out mode, I'm trying to see more of my content and interact at a higher level with patterns (in the future). For previewing, I'm simply trying to get a sense of how my site will look on different devices. Having these exist alongside each other doesn't seem to provide value but feels like it's more surfacing complexity. To be clear, I'm all for both controls -- just not intermingled with each other. |
This reverts commit 8b8f2fb.
scruffian
force-pushed
the
try/move-zoom-out
branch
from
849262a
to
b23f43d
Compare
What?
Related to #56806, moving the standalone zoom control into the PreviewDropdown. This aligns the display and zoom tools into one area, as they are directly related.
Previously, invoking zoom would hide the preview device controls (as the zoom UI was separate from the preview UI). With this change we don't need to get smart on that front; just include the like actions in the same area.
I am curious if we need to have this behind an experimental flag, not that it's much more integrated into the existing UI — rather than appended at the top of the toolbar. Sure, there are further refinements that the zoomed out view may hold, but it's nice to be able to see more of a page all at once.
How?
Testing Instructions
Screenshots or screencast
zooming.mp4
Follow-up
I set this zoom percentage to 50%, but it would be nice to have a "Zoom to fit" control, which would zoom out enough so you can see the entire page.
With that fit control in mind alongside 50%, we may need to be more clear about zooming back to 100%, like below. Although "Zoom to 100%" and "Desktop" have the same behavior. cc @WordPress/gutenberg-design.