Design for Position UI

[jameskoster]

CSS position has many permutations, and while we're unlikely to implement everything in one go it would be good to settle on a design that can serve us equally well in the short and long term.

Sticky (and potentially fixed) are currently being worked on in #46142 (originally started in: #44723).

Here's a riff on a design shared earlier by @jasmussen:

• Position control lives in the 'Advanced' panel. Previous explorations had it in the 'Layout' panel but I'm not sure it's a good fit:
  1. Only containers have a Layout panel, and it may be that you want to fix the position of a single block.
  2. All the controls in the Layout panel currently relate explicitly to child blocks, and position does not.
  3. Layout controls change based on whether the container has flow or flex layout, while position has no relation to that condition.
• A dropdown contains the different layout options, and based on the selection secondary controls are exposed.
• Fixed selection includes a matrix picker for easy position selection, and a Settings icon which exposes more granular control.
• Sticky selection includes a Settings icon where you can specify offset positioning along the X / Y axis.
• In List View, fixed-position blocks are separated, which essentially communicates the z-index value.

In the future we can add:

• Absolute selection, which would have the same secondary tools as Fixed.
• Relative selection which would not require any secondary tools:

Let's discuss.

[ramonjd]

In List View, fixed-position blocks are separated, which essentially communicates the z-index value.

Thanks for working on the designs!

How do you think it could work with, say, nested Groups that have fixed position enabled? I'm coming from the assumption that the list view represents a tree of elements.

The design does make elements sitting "on top" more accessible, but on the face of it, splitting the tree into fixed and scroll appears to me to diverge from the tree paradigm.

Just thinking out loud here: it would be ace to be able to switch the list view between a strict hierarchy (what it is now) and some representation of z-index order. Or not 😄 🤷

Or, in the opposite direction, are visual aids required at all in the list view given that a user can click on the sticky element and edit the properties?

[jameskoster]

are visual aids required at all in the list view given that a user can click on the sticky element and edit the properties?

I think it helps to quickly explain why the position of a block on the canvas is not reflecting the tree structure. But I agree we'll need to explore other options, as the separation doesn't work for nested fixed blocks.

[andrewserong]

Position control lives in the 'Advanced' panel.

Nice reasoning here! I think that makes for a really good pragmatic step for introducing the control, and good work honing in on all the conceptual details surrounding layout. I was chatting with @tellthemachines about this too, and I think you've made some great arguments for decoupling the concept of Position from Layout. In terms of block.json we can represent it as supports.position as its own block support potentially, rather than tying it to layout under supports.__experimentalLayout.allowPosition, which I've been doing in my explorations up until now.

Also, the idea of allowing relative + absolute positioning further down the track will unlock some very creative possibilities for laying things out with blocks, so that's another good argument for decoupling from container blocks (e.g. set a Group block to "relative" and then set a child Image block to "absolute" and nudge it off to the side a little for a deliberate aesthetic) 👍

In List View, fixed-position blocks are separated, which essentially communicates the z-index value.

I imagine moving things around in the list view based on position attributes could be tricky to implement. Though I think it's a good thing to explore, would this be a blocker for the initial implementation? I.e. in an initial implementation with sticky and top position, would it be acceptable if it weren't flagged in the list view, or do you think having some visual indication there is a blocker for usability?

Thanks again for splitting out this discussion! 🙂

[jameskoster]

Thanks for the words of encouragement!

would this be a blocker for the initial implementation?

No, certainly not a blocker :)

[tellthemachines]

Thanks for starting this discussion! I have a few thoughts to add:

Controls and implementation

With "fixed", "sticky", "absolute" and "relative" it seems increasingly like we are trying to implement a UI for CSS functionality. Is this really what we want? It might be good to take a step back, consider the needs of our users (not all of whom are familiar with CSS) and build from there, rather than taking the implementation as a starting point and building the tools around the CSS properties we can expose.

CSS position: sticky in particular is a tricky one. If we add a control that just toggles that property on a block, chances are it won't work as users expect it to, because in order to stick, the block needs to be in a container taller than itself and and it will only stick as far as its container is still on screen. This means that if a template is sectioned into areas, the sticky container will need to be in the outermost wrapper in order to stay sticky across the whole page.

We can solve this either with detailed instructions on how to make it work, or by making it work magically with JS. I suspect from a user point of view, a "magically working" experience will be much better.

List View

With the separation of positioned blocks into their own section in List View, we need to consider accessibility very carefully. Currently, List View is the most accessible way to navigate the editor. Its intent to mirror the document structure is crucial particularly when the interface is visually complex enough that we can no longer tell at a glance how many blocks we have on the page.

I anticipate that adding fixed or otherwise positioned blocks will only make the canvas harder to navigate and edit, and if List View no longer reflects the DOM order that can make tasks like moving blocks much harder. We should particularly consider that positioning often depends on a parent element (whether a sticky container, or a relatively positioned ancestor to an absolutely positioned block), in which case a DOM-accurate List View will be crucial to make sense of the whole.

[jameskoster]

As a designer I am always considering the needs of users :) With most of these controls, we need to make performing common actions quick and easy, but not at the expense of more granular control. "I want to make my header sticky" is a different proposition to "I want this one block to be fixed in position and not scroll". We need solutions that work for both. If we get the foundational elements right first, we can build on those to provide solutions for more specific use cases.

I'm hearing List View will be tricky, so we can look into it separately.

[tellthemachines]

As a designer I am always considering the needs of users :)

😄 yeah, that phrasing was probably a bit too vague. What I meant was to consider it functionality-first (what controls to expose and what they should do) as opposed to implementation-first (e.g. which of the CSS position values we should expose), because implementation can vary according to our needs.

In this case, I'm wondering the following:

• when making a block sticky, should it default to be sticky throughout the whole scrollable page, unless we explicitly set an area for it to be sticky within?
• What would a control for setting the "sticky area" look like?
• similarly with absolute positioning, are we positioning blocks page-wide, or will we allow an explicit container area to be set?

I think fixed is likely to be the most straightforward in terms of controls, because it will always be relative to the viewport. Perhaps we can start with that one?

[andrewserong]

Good questions!

when making a block sticky, should it default to be sticky throughout the whole scrollable page, unless we explicitly set an area for it to be sticky within?

I know it's likely confusing for users, but I quite like the browser default of sticky applying to the height of the direct parent of the currently selected block, as it allows for some quite creative designs (e.g. intentionally making a group block sticky for only part of a page, within a column etc), but I agree it's a really challenging one to communicate clearly in terms of usability 🤔

What would a control for setting the "sticky area" look like?

That's a really interesting idea. If we tried a control for selecting a sticky area, I'm also wondering how would it work? For an initial implementation of sticky/fixed, I'd love it if we can avoid depending on shipping JS to the site frontend, since we don't have a precedent for that within the block supports, so it could be a bit of a rabbithole.

I think fixed is likely to be the most straightforward in terms of controls, because it will always be relative to the viewport. Perhaps we can start with that one?

I like the idea of starting with whatever's going to be the simplest UX, but unfortunately so far, I've found fixed a bit harder to work with. With fixed we run into some UX / UI challenges with ensuring the correct positioning and width, and that there is enough padding for the space that the element would have otherwise taken up (browser default behaviour for sticky deals with the width and padding automatically). Here's a quick codepen for exploration:

Browser default sticky (note the the following paragraph is visible, the sticky div has full width)	Browser default fixed (note the paragraph is hidden behind the fixed element, the div is the width of its content)

Because of that, out-of-the-box sticky appears to get us closer to user-friendly behaviour in terms of the block behaving as it's expected to, but we run into the challenge of it being a hard concept to work with (parent / child relationship and spacing), whereas with fixed the controls might behave in more of a directly obvious way, but we then have a challenge of figuring out how to handle the spacing in a programatic way that works with the site layout. 🤔

Hrm... now that we're discussing the details of the trade-offs, I think both approaches are going to be pretty challenging! I think I'd lean a little more toward starting with sticky, since it doesn't require width controls or calculating and outputting site padding to account for it. It'd be great to be able to support both, though.

[jameskoster]

I think the most important thing to remember is that we are essentially creating a UI for CSS, so at the most foundational layer the controls should reflect the natural behaviour therein. So yes, a 'sticky' block should 'unstick' when its container scrolls out of view. It's also worth noting that this is a fairly advanced control, and non-technical users less likely to interact with it – more likely they will encounter its effects as a part of theme / pattern selection. Once we get the foundational layer right we can explore creating UIs for dedicated use cases.

[jameskoster]

One other option we might consider for the fixed position would be to permanently display the position picker, which emphasises the simpler way to set position at the expense of some visual real estate:

As before we could do the same thing for the absolute positioning option.

[jasmussen]

I'm coming in late to this one, sorry was under the weather last week. Lots of good thoughts here, lots of excellent mockups. A few quick thoughts:

• I don't think the goal should be to reimplement CSS. But ultimately that's still what we're bound by. We can find a good UI for it by starting with the most salient pieces, implementing them well, balancing prominence, and providing good patterns and templates for these.
• In that vein, I'd omit relative and static for now as explicit choices. Static can be implied as a default/unset, and relative would be interesting to see if we could do without, but add if we need to.
• As far as the 9-grid, I like that interface a lot. It provides smart handy defaults for the majority of positions (though I'd omit the one in the center, making it an 8 grid).
• The settings toggle for custom inputs working like it does for font size is smart. But I'd make it a toggle instead of the popover, so the grid is replaced by the inputs. That way we don't need to highlight your custom position once you close the popover.
• I don't think "Advanced" is the right place for this. I still think Layout is, and so long as it's a non-default ToolsPanel control, it manages its prominence there.

Here's a quick things at taking Jay's ingredients and tweaking them a bit:

These actually integrate another idea of Jay's, which is to integrate a "quick shortcut" dropdown inside the input. It's like the unit picker, a sort of shorthand just like the unit control. What do you think?

[jameskoster]

I realize that a position toolspanel with only one option is kind of useless, but would a collapsible panel be better there?

It's not much consolation but it wouldn't be a single option. If we use a collapsible panel then we'll be back in the position of having to surface a 'Default' value. It might work?

[jasmussen]

That might work, yes, but it would still be dependant on the split inspector graduating, at least if we were to roll it out beyond the Group. But if we did limit it to that, then maybe a position panel might be okay 🤔

About the inline positional picker. How would you feel about finding a way to make it into a popover? It takes up a fair bit of space, and I think there's some sense in reusing the pattern from the Cover matrix button, which is a popover as well.

[jameskoster]

That might work, yes, but it would still be dependant on the split inspector graduating

I guess this design could go in the Advanced panel as well. But alongside everything else in there the usability degrades quite a bit imo. Position is complex and warrants its own space.

About the inline positional picker. How would you feel about finding a way to make it into a popover?

In this context I feel that pattern would put too much emphasis on the dropdown. After selecting that you want a fixed position, the dropdown effectively becomes secondary. If we used the accordion panel you can always just collapse it to reduce unwanted distraction.

There might be other options though, like a two column layout:

[andrewserong]

But I have a small concern that it departs in behavior from existing toolspanels. It's effectively a new panel style, which would not be trivial for the near term.

I have the same concern (similar to when the concept was suggested for the layout panel in #45833 (comment)) in that it introduces a complexity to the concept of the panel, where the plus icon becomes an action that affects block state, along with the minus icon that removes block state. While the UI looks fairly simple, this isn't something supported by the ToolsPanel and introduces a different kind of interaction with panels than what we already have in the editor UI, which opens up some accessibility challenges. E.g. what does it mean to add a position, how does a user know what they're about to do before they click on the plus icon when in other cases the plus icon is a drop-down menu that exposes options.

If we use a collapsible panel then we'll be back in the position of having to surface a 'Default' value. It might work?

I quite like the collapsible panel idea for position, though, and it side-steps the problem of creating a new panel type. I'd be happy to try doing that.

Personally, I'm still in favour of having a 'Default' value in the UI so that a user can quickly see what the current state is, rather than inferring it based on the absence of a control being visible. In that respect it's sort of similar to how the font-size dropdown displays 'Default' when no font size is selected (on themes with lots of font-sizes). What's the reasoning behind wanting to hide it?

[andrewserong]

Update: for fun, over in the WIP PR, I've had a go at moving the control over to a separate collapsible Position panel. Seems to work pretty well so far: #46142 (comment)

[simison]

While your use-case is clearly focused more on the header, would this also allow creating UIs for floating modals and things like cookie banners?

Those are trickier than header because there should be a way to hide them for most of the time so that they aren't obscuring the view all the time.

[jameskoster]

While your use-case is clearly focused more on the header

Actually we've tried to design all the concepts here to be block-agnostic.

Modals are a special case due to the requirement of trigger / dismissal components, there's a lot more to it than just positioning. We can perhaps look at the Navigation block's Overlay option for inspiration. When we get there, the position controls we're working on here should contribute effectively as a part of any modal creation flow, but can probably be de-emphasised a bit since you'd generally want modals to be fixed / center aligned by default.

[jasmussen]

One aspect of positioning presets is to find good values to apply for each preset. It might be useful to explore exactly what such presets might look like, so I took a stab in this codepen: https://codepen.io/joen/pen/wvXLORR?editors=1100

It has 9 preset positions, and each of them are applied by combining two classes, such as "is-top is-left". This involves not just top/left/right/bottom values, but for middle and center positions, it needs a little translate as well. Is that feasible? Are there good alternatives, maybe calc-based values?

[andrewserong]

Is that feasible?

Conceptually the way the WIP work has been explored so far, we should be able to output additional rules. We'll likely need to add the transform properties to the allowed list for kses, which we need to do for top/right/bottom/left anyway, so I think it's probably feasible. I also quite like the utility classnames for these preset-like values, too 👍 I suppose we'll still want to support direct values (at least technically) for designs that want a deliberate offset (e.g. 2em from top, or 2em from bottom, etc), but this looks promising to me.

[jasmussen]

I suppose we'll still want to support direct values (at least technically) for designs that want a deliberate offset (e.g. 2em from top, or 2em from bottom, etc)

Yes, we'll want to support manual values. Manually centering, is going to be a challenge, the translate hack isn't easy to grok. But it's a challenge we can meet, I'm sure.

[jameskoster]

Manually centering, is going to be a challenge

If we consider the user flows I think it might be ok.

In most cases I suspect folks would select MC using the preset which provides the context they need to interpret the controls that are revealed when switching to manual config. An important part of this being that the controls necessary to achieve the preset are revealed (and populated) when you make that switch.

Going directly to manual config without choosing a preset is more advanced, and we can perhaps assume that these users understand the different positioning methods. Still, we can potentially hide the transform control by default and make it possible to add via the tools panel.

[jasmussen]

Perhaps we can get very far with these 9 presets, and then top/right/bottom/left manual controls 🤔

[Faton1995]

Hello, is it not possible to integrate this in the following way: When a block is fixed, it remains fixed at the same position as it is displayed in the full site editor?