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

Enhance the Placeholder to better scale and adapt #18800

Closed
jasmussen opened this issue Nov 28, 2019 · 6 comments
Closed

Enhance the Placeholder to better scale and adapt #18800

jasmussen opened this issue Nov 28, 2019 · 6 comments
Labels
[Status] In Progress Tracking issues with work in progress

Comments

@jasmussen
Copy link
Contributor

The "Placeholder", or the setup state of the block, is one of the most important pieces of the block editor. It serves to:

  • Provide quick and easy setup of more advance blocks
  • Provide slots in templates that users can "fill in"
  • Provide helpful next steps

The component has been with us from the start. It has received many new features, but it has not been revisited in context of other features that were added, such as nested blocks or narrow slots as part of other compound blocks. In some cases it does not scale down beyond being a top level block:

image

This pull request is a first attempt at improving the scale of the placeholder: #18745:

69622478-4d0f7a00-1041-11ea-87e6-3e8439a6210e

But some of the design decisions made in that PR could use additional conversation and insight, and it could perhaps be informed by some of the efforts being explored in #18667. Some questions to ponder:

  • What breakpoints should there be?
  • What is the role of the icon, title, and description in the component? Do we need more, or less?
  • What should be shown at the smallest possible breakpoint, how small should that be, and how should it behave?
  • What is the relationship between controls available in the placeholder state, vs. them being present in the block toolbar after the fact?
  • How can we reduce the visual appearance further? This could benefit compound blocks such as the Collage Gallery from CoBlocks.

Collage Gallery:
Screenshot 2019-11-28 at 09 59 44

Mockups

Building off of mockups in #18667, here are some ideas to help the discussion along:

Image Placeholder

The base placeholder is vastly reduced to a single title, no icons, and a single primary button. This keeps it helpful for when you need quick access to any of those actions in large breakpoints, but keeps the appearance simple, which matters for templates that might include multiple placeholders.

When the placeholder is selected, it's focused and the block toolbar is present:

Placeholder has focus

By left-aligning content, (right aligned in RTL languages), we can provide a natural balance to additional controls such as colors in the setup state:

cover

This left aligned pattern can then scale to the toolbar itself:

cover 2

In very narrow context, we reduce the placeholder to a single word and button:

narrow

What does the button do, then? Does it expand the placeholder to full width in a modal/light-boxy fashion? Does it simply open a popover with options for browse or add a URL?

Your thoughts are welcome!

@jasmussen jasmussen added the Needs Design Feedback Needs general design feedback. label Nov 28, 2019
@ZebulanStanphill
Copy link
Member

ZebulanStanphill commented Nov 29, 2019

The Add… button could open a dropdown similar to the Replace button proposed in #16200.

image

@karmatosed
Copy link
Member

What breakpoints should there be?

I think we should be as fluid as we can, with it growing. However I think we can have 3 to start as fixed points:

  • Smaller screens: for example an Android phone
  • Tablet screens: for example iPad
  • Monitor screens: starting from 13 inch laptop

What is the role of the icon, title, and description in the component? Do we need more, or less?

I actually don't see the icon as important here and happy if it goes. I have similar feelings over title and description if they become a call to action of 'add your image' for example.

What should be shown at the smallest possible breakpoint, how small should that be, and how should it behave?

I think that relates to my suggestion above of a smaller phone. I think it should clear as much out of way as possible.

What is the relationship between controls available in the placeholder state, vs. them being present in the block toolbar after the fact?

I would actually like placeholders to move back to just being that. The changes there would be for example dragging into the interface (I think showing a hit area interaction is still useful feedback).

How can we reduce the visual appearance further? This could benefit compound blocks such as the Collage Gallery from CoBlocks.

How minimal can we make them? Let's get them as minimal as possible!

The worst we have right now are button stacks (3 in places), we don't need that and things like the upload icon aren't giving ups anything here.

@jasmussen
Copy link
Contributor Author

The Add… button could open a dropdown similar to the Replace button proposed in #16200.

Yes, that's a good idea. There's potentially also some new patterns from #18667 we can leverage there:

replace menu

@jasmussen
Copy link
Contributor Author

Smaller screens: for example an Android phone
Tablet screens: for example iPad
Monitor screens: starting from 13 inch laptop

I think we actually need to go way smaller than that, so as to accommodate something like the coblocks gallery. For example a phone query would be around 320px, which should be enough to fit three buttons. But on a phone with the coblocks gallery, each of the placeholders should probably be reduced to a single button, i.e. have a query that is < 160px.

In #18745, I used these sizes:

  • Larger than 320px applies size-lg (size large) to the Placeholder component.
  • Between 320px and 160px applies size-md (size medium)
  • Below 160px, applies size-sm (size small)

So those three happen below the phone breakpoint.

I would actually like placeholders to move back to just being that. The changes there would be for example dragging into the interface (I think showing a hit area interaction is still useful feedback).

Solid point. This needs a visual for what happens when you drop an image on a placeholder — this is an interaction that could need a love in what we have today. @pablohoneyhoney do you have any thoughts here?

@pablohoneyhoney
Copy link

I would actually like placeholders to move back to just being that.

Agree, reducing the elements of the interface to its most relevant and primary actions lowers the cognitive process. Reducing copy helps, even with localization.

@karmatosed karmatosed added [Status] In Progress Tracking issues with work in progress and removed Needs Design Feedback Needs general design feedback. labels Dec 18, 2019
@jasmussen
Copy link
Contributor Author

I'm actually going to close this one as the primary purpose has been achieved with element queries in the placeholder component. Additional enhancements can be ticketed separately.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Status] In Progress Tracking issues with work in progress
Projects
None yet
Development

No branches or pull requests

4 participants