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

Discovery - define which page elements should be zoomed, and which should not #2791

Closed
MackenzieHartung opened this issue Jul 10, 2019 · 9 comments
Labels
Task Tasks which do not involve engineering

Comments

@MackenzieHartung
Copy link

As a user I want to be able to zoom out/in elements on the editor page. Not all elements should be capable of zoom in/out.

AC1: Discovery - define which page elements should be zoomed, and which should not (e.g. Navigation, block borders)

@MackenzieHartung MackenzieHartung added the Task Tasks which do not involve engineering label Jul 15, 2019
@swissspidy
Copy link
Collaborator

So there is this interesting WIP pull request on the Gutenberg repository which also introduces that notion of zooming.

@miina
Copy link
Contributor

miina commented Aug 7, 2019

Looks like the WIP PR got closed, also, it looks like it's purpose was more similar to the Instagram-like focus than actual Zooming -- it seemed to separate the block for editing without distractions.

To clarify:
Is the goal of this discovery to figure out

  • a) How to keep some of the elements the same size even while the user is zooming (using the default zoom)? For example so that only the (selected) Page would zoom when the user is zooming and the other elements, such as the block navigation etc. would remain the same?
  • b) Add a functionality which would programmatically zoom specific elements? E.g. there would be buttons which would zoom the Page in-out while everything else would stay the same.

Did you understand something like this or something different over the call today? Would appreciate your thoughts. cc @kienstra @swissspidy

@kienstra
Copy link
Contributor

kienstra commented Aug 7, 2019

Hi @miina,
Looking over my notes from the call, your 2 points above look right.

a) Yes, I think it was mentioned that the elements that appear on the front-end should be able to zoom, like the Page. While any editor-specific elements, like the toolbar, shouldn't be able to.

b) I'm not sure if there was discussion about 'programmatically zooming' in the call, though that's not to say it doesn't apply. I'm not sure about the specifics about how it would happen.

@swissspidy
Copy link
Collaborator

How to keep some of the elements the same size even while the user is zooming (using the default zoom)?

If with "default zoom" you mean zooming in the browser using Ctrl++ / Ctrl+-, then I don't think it's technically possible to restrict this to a certain area. Nor would that be advisable to implement.

Add a functionality which would programmatically zoom specific elements? E.g. there would be buttons which would zoom the Page in-out while everything else would stay the same.

Yes, that was my understanding. Click on zoom button -> page is displayed bigger, which makes it easier to edit -> block toolbar etc. stay small.

@miina
Copy link
Contributor

miina commented Aug 7, 2019

Nor would that be advisable to implement.

Yep, 100% agreed with that.

Yes, that was my understanding. Click on zoom button -> page is displayed bigger, which makes it easier to edit -> block toolbar etc. stay small.

Looks like one option for doing that could be using scaling via transform, basically what we're doing when reordering pages and previewing templates. Not sure how accurate it would look like though, we've had issues with positioning the element before to match the view, pure scaling doesn't seem to work.

Found an example (see under "Zooming inside a container") searching which uses transform for that.

@miina
Copy link
Contributor

miina commented Aug 8, 2019

Is the main goal of this feature to be able to have better editing experience by zooming into the currently active page? Or was there any other goal behind it?

One option could be adding just one zooming point, e.g. zoom in for scaling X% and zoom back out.

Another thing to consider is that if we're zooming just the one active page then this means that the room that we have for this page would need to stay the same (since everything else around it is staying the same), so we should handle the zoom within a container.

An alternative could be having a "zoom mode" (a bit more similar idea to the upstream PR that got closed) which would:

  • Turn on the Fullscreen mode.
  • Display the active page X% larger.
  • Adjust the styling so that the Page would have enough room for being X% larger while still keeping the relevant settings etc. visible. (Since Fullscreen would hide the menus, we'd have more room)

Not sure. Thoughts?

@swissspidy
Copy link
Collaborator

My understanding was that this would allow for a better editing experience because zooming in on the current page would hide the other elements like the menus, etc. (since you want to focus on editing that page). So more like the second version you describe.

@cathibosco
Copy link

Checking my understanding: So this is similar editing a post using elements of classic editor in "Distraction Free Mode" without removing the document and block editor and tools.

https://canddstudios.d.pr/Gqtk21

@miina
Copy link
Contributor

miina commented Aug 21, 2019

Correct, and with displaying the Page larger as normal as well ("zoomed").

We'll discuss/confirm this in a few hours today.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Task Tasks which do not involve engineering
Projects
None yet
Development

No branches or pull requests

6 participants