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

Try: Make site editor responsive. #26021

Merged
merged 13 commits into from
Nov 5, 2020
Merged

Try: Make site editor responsive. #26021

merged 13 commits into from
Nov 5, 2020

Conversation

jasmussen
Copy link
Contributor

The site editor is currently not usable on mobile:

before

This PR does a number of things to improve that:

  • It fixes the white screen issue
  • It hides pinned items entirely on mobile — these modal toggles are available in the More Options menu.
  • It collapses the label, so it says "Update" instead of "Update Design", on mobile.
  • It hides the same undo/redo/tools/block selector buttons on the site editor, that are hidden on the post editor.

This improves things a fair bit:

Screenshot 2020-10-12 at 11 56 57

I wouldn't call this the end of the road, there's a great deal of polish that reains possible:

  • The centered controls which are still in a design flux, probably shouldn't be optimized until we know how they will look like.
  • There's some component usage that is treated differently based on post vs. site editor, this could be reduced and simplified.

But for now, this is a decent start.

@jasmussen jasmussen added [Type] Enhancement A suggestion for improvement. Mobile Web Viewport sizes for mobile and tablet devices labels Oct 12, 2020
@jasmussen jasmussen self-assigned this Oct 12, 2020
@jasmussen
Copy link
Contributor Author

This addresses feedback from #25134 (comment).

@github-actions
Copy link

github-actions bot commented Oct 12, 2020

Size Change: +65 B (0%)

Total Size: 1.21 MB

Filename Size Change
build/edit-site/index.js 22.5 kB +4 B (0%)
build/edit-site/style-rtl.css 3.91 kB +32 B (0%)
build/edit-site/style.css 3.91 kB +32 B (0%)
build/edit-widgets/style-rtl.css 3.12 kB -2 B (0%)
build/edit-widgets/style.css 3.12 kB -1 B
ℹ️ View Unchanged
Filename Size Change
build/a11y/index.js 1.14 kB 0 B
build/annotations/index.js 3.78 kB 0 B
build/api-fetch/index.js 3.45 kB 0 B
build/autop/index.js 2.84 kB 0 B
build/blob/index.js 665 B 0 B
build/block-directory/index.js 8.72 kB 0 B
build/block-directory/style-rtl.css 943 B 0 B
build/block-directory/style.css 942 B 0 B
build/block-editor/index.js 132 kB 0 B
build/block-editor/style-rtl.css 11.1 kB 0 B
build/block-editor/style.css 11.1 kB 0 B
build/block-library/editor-rtl.css 9.01 kB 0 B
build/block-library/editor.css 9.01 kB 0 B
build/block-library/index.js 146 kB 0 B
build/block-library/style-rtl.css 7.9 kB 0 B
build/block-library/style.css 7.89 kB 0 B
build/block-library/theme-rtl.css 792 B 0 B
build/block-library/theme.css 793 B 0 B
build/block-serialization-default-parser/index.js 1.88 kB 0 B
build/block-serialization-spec-parser/index.js 3.1 kB 0 B
build/blocks/index.js 48.1 kB 0 B
build/components/index.js 172 kB 0 B
build/components/style-rtl.css 15.3 kB 0 B
build/components/style.css 15.2 kB 0 B
build/compose/index.js 9.81 kB 0 B
build/core-data/index.js 12.5 kB 0 B
build/data-controls/index.js 772 B 0 B
build/data/index.js 8.77 kB 0 B
build/date/index.js 31.8 kB 0 B
build/deprecated/index.js 768 B 0 B
build/dom-ready/index.js 571 B 0 B
build/dom/index.js 4.46 kB 0 B
build/edit-navigation/index.js 11.2 kB 0 B
build/edit-navigation/style-rtl.css 881 B 0 B
build/edit-navigation/style.css 885 B 0 B
build/edit-post/index.js 306 kB 0 B
build/edit-post/style-rtl.css 6.41 kB 0 B
build/edit-post/style.css 6.39 kB 0 B
build/edit-widgets/index.js 26.3 kB 0 B
build/editor/editor-styles-rtl.css 480 B 0 B
build/editor/editor-styles.css 482 B 0 B
build/editor/index.js 42.8 kB 0 B
build/editor/style-rtl.css 3.85 kB 0 B
build/editor/style.css 3.85 kB 0 B
build/element/index.js 4.65 kB 0 B
build/escape-html/index.js 735 B 0 B
build/format-library/index.js 7.7 kB 0 B
build/format-library/style-rtl.css 547 B 0 B
build/format-library/style.css 548 B 0 B
build/hooks/index.js 2.16 kB 0 B
build/html-entities/index.js 623 B 0 B
build/i18n/index.js 3.57 kB 0 B
build/is-shallow-equal/index.js 712 B 0 B
build/keyboard-shortcuts/index.js 2.52 kB 0 B
build/keycodes/index.js 1.94 kB 0 B
build/list-reusable-blocks/index.js 3.11 kB 0 B
build/list-reusable-blocks/style-rtl.css 476 B 0 B
build/list-reusable-blocks/style.css 476 B 0 B
build/media-utils/index.js 5.34 kB 0 B
build/notices/index.js 1.79 kB 0 B
build/nux/index.js 3.42 kB 0 B
build/nux/style-rtl.css 671 B 0 B
build/nux/style.css 668 B 0 B
build/plugins/index.js 2.56 kB 0 B
build/primitives/index.js 1.43 kB 0 B
build/priority-queue/index.js 791 B 0 B
build/redux-routine/index.js 2.85 kB 0 B
build/reusable-blocks/index.js 3.05 kB 0 B
build/rich-text/index.js 13.2 kB 0 B
build/server-side-render/index.js 2.77 kB 0 B
build/shortcode/index.js 1.69 kB 0 B
build/token-list/index.js 1.27 kB 0 B
build/url/index.js 4.06 kB 0 B
build/viewport/index.js 1.84 kB 0 B
build/warning/index.js 1.14 kB 0 B
build/wordcount/index.js 1.22 kB 0 B

compressed-size-action

@@ -86,11 +85,13 @@ html.interface-interface-skeleton__html-container {
left: 0;
background: $white;
color: $gray-900;
width: 0;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is really close. Something about this style is breaking the inspector panel on both the site editor and the post editor. You can see that here:

image

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome catch, I'll need to address that! Thank you.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright this should be fixed.

@jasmussen
Copy link
Contributor Author

Alright this one should be ready to go.

It would be really nice to get this one in soon, both so the experience isn't totally broken on mobile, but also so that actually optimizing for and considering mobile can be easier as development moves on.

Copy link
Member

@david-szabo97 david-szabo97 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The inserter panel and name of the panel are not showing up for me.

image

@jasmussen
Copy link
Contributor Author

Argh how could I miss that !?

Taking a look, thank you!

@jeyip
Copy link
Contributor

jeyip commented Oct 27, 2020

I just pushed a commit to address this comment, which seemed to be causing layout issues for mobile. I think it might be able to hold us over until we rework the mobile experience altogether. The header at smaller viewport widths should now look like this:

Screen Shot 2020-10-27 at 1 58 21 AM

I pushed it here because I thought it would be easier to test, discuss, and potentially include with the fixes made in this pull request, but I'm more than happy to rebase and remove the commit and include it in separate PR. Would love to hear your thoughts @jasmussen

@jasmussen
Copy link
Contributor Author

Awesome.

There are a lot of good CSS changes in this PR that I believe will hold us over for a while wrt the mobile site editor. But it's still blocked on the white screen, and I think I'll need some help getting that working. Behold:

white

That white screen is actually the "left sidebar" being open, all the time.

@jeyip
Copy link
Contributor

jeyip commented Oct 28, 2020

There are a lot of good CSS changes in this PR that I believe will hold us over for a while wrt the mobile site editor. But it's still blocked on the white screen, and I think I'll need some help getting that working. Behold:

I pushed changes and the WSOD should now be addressed. Would love to hear from @david-szabo97 @Copons @Addison-Stavlo @vindl if there are any concerns. I moved the logic to handle conditional rendering of the Left Sidebar up to its parent, edit-site/editor

2020-10-27 20 13 28

@jasmussen
Copy link
Contributor Author

Stellar work, @jeyip, I'm seeing this, and it's a substantial improvement:

featured

Thanks so much, I hope we can land this soon!

@david-szabo97
Copy link
Member

I pushed changes and the WSOD should now be addressed. Would love to hear from @david-szabo97 @Copons @Addison-Stavlo @vindl if there are any concerns. I moved the logic to handle conditional rendering of the Left Sidebar up to its parent, edit-site/editor

Any reason to move it to the parent? I prefer it to be in a separate component so less clutter in the editor. Opening the Inserter will now re-render the whole Editor if it's moved to the parent.

@jeyip
Copy link
Contributor

jeyip commented Oct 29, 2020

Any reason to move it to the parent?

Good question!

It's because the InterfaceSkeleton component is designed in such a way that it expects us to pass in a false-y value when an interface element (like leftSidebar, header, footer, etc.) should not be rendered.

{ !! leftSidebar && (
<div
className="interface-interface-skeleton__left-sidebar"
role="region"
aria-label={ mergedLabels.leftSidebar }
tabIndex="-1"
>
{ leftSidebar }
</div>
) }

In edit-site, however, we had the left sidebar set up in such a way that it was always truthy

<InterfaceSkeleton
labels={ interfaceLabels }
drawer={
<NavigationSidebar />
}
leftSidebar={
<LeftSidebar />
}

This was leading to the unexpected behavior we were seeing with the mobile wsod. The InterfaceSkeleton was always rendering a leftSidebar wrapper, even when the inserter wasn't "open". This was why I opted to move the logic for left sidebar rendering into the edit-site editor component.

Opening the Inserter will now re-render the whole Editor if it's moved to the parent.

Hmmm...this is a good point. I thought about alternative approaches, but I don't see any immediate solutions. I think we'd have to remove interface skeleton entirely to address unnecessary re-render and the wsod? Would also love to hear if you have any ideas @david-szabo97

@jasmussen
Copy link
Contributor Author

I wonder if such a skeleton refactor should block this PR from landing, given:

  • the site editor is currently unusable on < 600px
  • your approach is "no worse" than what's been shipping for many months in the post editor

In that vein, we could consider this a regression fix with an opportunity to refactor the skeletons for the benefit of both editors?

@jeyip
Copy link
Contributor

jeyip commented Oct 30, 2020

Ah I should have clarified @jasmussen. I completely agree with your sentiments. I think, in the worst case scenario, we should move forward with the changes in this PR for the reasons you listed above.

I was interested in hearing from David to see if he had ideas about solutions that would meet both criteria of:

  • Avoiding a rerender of the entire editor
  • Addressing the mobile wsod

@david-szabo97
Copy link
Member

Since the implementation is identical to the Post Editor, I think we are good to go. I can't think of any easy way to fix the rerender for now.

We will definitely need to rethink the InterfaceSkeleton and Editor. I don't think they are going to be bottlenecks for a while but they are the root of the whole Gutenberg so it'd be great to fix them up a little bit to avoid all that unnecessary rerenders.

Copy link
Member

@david-szabo97 david-szabo97 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One thing I noticed, we can open the Navigation sidebar by clicking on the name of the current template then clicking on "Browse templates". This opens the sidebar but there is no way to close it.

The name of the template in the header also gets pushed and it is no longer visible. (If you resize while the sidebar is open you will see that the name of the template is showing up once your browser is larger.)

image

After all, since this PR has been going on for a while, we would have a good foundation once this PR is merged, then we can address the issues coming up.

@jasmussen
Copy link
Contributor Author

Thank you for the review David! I would agree there's very ripe ground for refactoring this, and it should be done.

One thing I noticed, we can open the Navigation sidebar by clicking on the name of the current template then clicking on "Browse templates". This opens the sidebar but there is no way to close it.

This observation, I think, is one of the best reasons for moving ahead with this, even if it isn't optimal. This is the sort of bugfix that has to help inform the sidebar work, which we can only discover when it's in some state of functional.

I'm going to give this a rebase, and see if that helps the checks pass.

jasmussen and others added 13 commits November 5, 2020 12:53
Flex bases of 335px were added to the left and right site editor header toolbars to prevent their children from collapsing when shrinking the viewport. This, however, did not account for tbehavior at smaller screen widths (tablet / mobile), and caused layout issues.

To address this, we use breakpoints to define the 335px flex bases as desktop specific affordances.
The InterfaceSkeleton component coordinates the general layout and styling of the site editor and post editor pages. It expects specific behavior from its props. For example, if the LeftSidebar is open, InterfaceSkeleton expects to be passed JSX markup as the leftSidebar prop. Otherwise, if the LeftSidebar isn't open, InterfaceSkeleton expects a null or falsey leftSidebar prop. InterfaceSkeleton styling depends on this behavior.

In edit site, the LeftSidebar prop passed into InterfaceSkeleton was always a truthy value. As a result, InterfaceSkeleton was improperly accounting for a LeftSidebar, even when it was unmounted from the screen.

These changes move the logic to determine when the sidebar should "open" up from the LeftSidebar component itself to its parent. This allows us to pass JSX markup to the InterfaceSkeleton when the inserter is open, and a falsey value when the inserter is closed.
@jeyip
Copy link
Contributor

jeyip commented Nov 5, 2020

I rebased master again because there was still a failing (seemingly unrelated) e2e spec.

@jeyip
Copy link
Contributor

jeyip commented Nov 5, 2020

All specs are now passing 👍 Going to go ahead and merge the PR.

One thing I noticed, we can open the Navigation sidebar by clicking on the name of the current template then clicking on "Browse templates". This opens the sidebar but there is no way to close it.

Thanks for finding this @david-szabo97.

I made an issue here to track the problem you pointed out.

The name of the template in the header also gets pushed and it is no longer visible. (If you resize while the sidebar is open you will see that the name of the template is showing up once your browser is larger.)

I wonder if we want the interaction here to actually match the inserter, where, at smaller viewports, the sidebar actually occupies the entire screen. Either way, this isn't ideal either, and I made another issue to track this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Mobile Web Viewport sizes for mobile and tablet devices [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants