Design concepts for PR #44770

[jameskoster]

The design discussion in #44770 was getting a bit distracting, let's bring that conversation here so that the PR can focus on implementation.

Getting the PR into a good spot is tricky because we need to concentrate not only on its immediate focus, but also keep one eye on the future upgrades we have in mind, most notably:

1. The addition of intrinsic browsing in the 'frame'.
2. Moving lists (like Templates and Template Parts in the short term, and Content in the future) to the management area as drilldowns. This will be critical in getting the mobile experience right and is a concession we may have to make in 44770.
3. Adding Style and Navigation management to the management area.

All that said, here's the latest design concept we have:

44770.mp4

The trickiest part to get right seems to be the Edit button, particularly how it connects to the frame.

Besides this we also need to finalise design details like; spacing around the frame, colors/dimensions of the management area, including some visual separation of content items.

[jasmussen]

Thank you for sharing, this is coming together well. I think the larger frame can work to add space for controls, including those you added at the bottom. It would also be interesting to have the edge of the frame surface a resize cursor, so you can manually scale down, or up and snap into "edit mode".

The Edit button, the placement of it, and the controls outside, remains one of the bigger challenges. I think the current placement works, as it has context to the frame itself. Though I'd omit as many controls as possible — it's always easy to add back once it's clear how necessary they are, but it's hard if they are there from the start. For example, I'd omit the home icon, and the external link button.

The "pizzaplanet.com" URL shown in context of the Edit button adds context that makes me think this could potentially sit geographically elsewhere, and still work, if for example we wanted the frame to be closer to the edge. This would likely be useful for cases where the frame will be used to show list views, such as templates or otherwise.

Should we put Pages and Blog under a "Content" drilldown?

---

I also took #44770 for a spin and have some feedback on that PR specifically. Here's what it looked like in my testing:

Mainly the simpler navigation by removing the Browse/Editor links present in earlier versions, already improves things.

There's an awkward focus style around the site logo/w button:

Probably the most important next step to figure out, is where to put the edit button if not inside a faux-browser-bar like this one:

As noted, I think above can work. Probably also to the left can work.

In your prototype, this back chevron sits only on drilldown pages, not on the main page. I.e. it's not a back to dashboard arrow. Should it be?

Speaking of, there are some immediate metric things we can start working on in the PR, to match your prototype here:

• The width of the sidebar
• The alignment of the chevron under the W logo, and the wider indent of other menu items
• The button metrics and colors

PR for comparison:

[youknowriad]

I tried improving the alignments and colors of the sidebar in the last commit. What sidebar width should I be using?

[robglidden]

Should we put Pages and Blog under a "Content" drilldown?

For UX, I'd suggest exploring organizing by a site's actual, or user-perspective, hierarchy.

IE the good old WordPress template hierarchy, which, on reflection, is the site hierarchy. From top-down, 6 site areas:

Homepage
Pages
Posts
Archives
Not Found
Search

Probably a very user-intuitive list.

And right there, just not so obviously, in the traditional template hierarchy chart, though that was drawn in a more bottom-up classic theme-programmer way, rather than a user's site editing viewpoint.

Benefit: the site editor UX as it builds out and drills down, will work with, rather than hide/reorganize/rename/fight, the site architecture. And leverage the user-intuitive aspects of the still-essential template hierarchy.

[jasmussen]

I tried improving the alignments and colors of the sidebar in the last commit. What sidebar width should I be using?

Try 360px?

[youknowriad]

I've used 320 as 360 felt a bit too big for me. you can tweak the number to try.

[jameskoster]

On the subject of resizing, we should decide how template parts appear in the frame. If they match the editor we get the following:

The resize handles are awkward because the canvas is non-interactive. But in general, the 'focussed' appearance (dark grey space around the template part) feels unnecessary, as does the full-height frame.

Here's an alternative, where the frame wraps the template part, and the resize handles appear outside:

And here's the concept applied when a template (or item of content) is visible in the frame:

[jasmussen]

Oh I like when the frame itself becomes the canvas. Makes me wonder if those resize handles could exist also next to the default frame, but perhaps be invisible until the cursor is near.

[jameskoster]

Do you mean like in the third gif? Or are you suggesting that the resize handles persist in both browse and edit views?

[jasmussen]

Yes, in the 3rd gif exactly, but with the resize handles invisible until your cursor is near the browser edge.

[mtias]

We also should consider if the handle just changes the split between sidebar / canvas or if it only resizes the frame. I think we should try having only one handle and a bit more separated from the frame.

[jameskoster]

The Edit button, the placement of it, and the controls outside, remains one of the bigger challenges

Let's explore some options:

Figma here.

[jasmussen]

Took it for a spin:

This actually works pretty well. There's some design work to find to make it feel totally right — something between what Jay has and this — but in practice, it feels nice. I like the context of the edit button to the frame, even if, as noted, the design isn't totally right yet.

[jameskoster]

Thinking a little further down the road and considering other elements we'll need to tackle (like the admin bar), I have another concept to share for the Edit button:

admin-bar.mp4

This demonstrates how folks can move between viewing the frontend of their site to editing / managing, and back again. I appreciate we'd need loading states between the frontend and editor/browse view, but it gives a general flavor.

In terms of the PR, the changes would be:

• Update site title to link to the frontend
• Include the entity name in the edit button label (this is important because the drilldown panel and browse frame may not always be in sync)
• Position edit button adjacent to site title
• Display menu icon when hovering the W button in the Edit view
• Style / spacing polish

What do y'all think?

[jasmussen]

I think there's a lot to like bout the frontend inclusion as you've explored, but that this particular aspect is probably something to hone for the future.

Just for the PR in question, though, I like the "Edit Index template" button idea. Can it just be "Edit Index"? We'll probably need all the space we can get if it is to sit in the sidebar on the left.

I don't love how the editor bar animates in from the top, I feel like we had some better patterns earlier on. Mainly it feels like it's a curtain that sits separatly from the W logo. I'm blissfully unaware of how hard this would be to animate in practice, so feel free to shoot this down, but what if the viewport was a mask that when it scaled up simply revealed that the editor bar was there all along?

[jameskoster]

I think there's a lot to like bout the frontend inclusion as you've explored, but that this particular aspect is probably something to hone for the future.

I agree, but still think it's a useful dot to connect, since we're going to have to tackle the admin bar sooner or later. If we keep one eye on that now we can avoid making trouble for ourselves in the future.

Can it just be "Edit Index"

Potentially, yes. My reasoning for the 'template' suffix is that the context is useful when templates have ambiguous names (e.g. 'Edit Category'), or names that are easily confused with content (e.g. 'Edit Home').

I don't love how the editor bar animates in from the top

Aside from the animation which we can tweak, the detachment was my interpretation of Pablo's comment here, particularly this part:

The editor top bar (editor header) shall move independently when in transition to browse mode, as a distinct material that doesn’t belong to the canvas, it is a control device that rather pertains to the system that helps me manipulate my site.

This is an important element to get right because it seems it is not trivial to detach. Did you have any other thoughts on this?

[jasmussen]

I'll keep thinking about the animation 👍 👍

[robglidden]

Should we put Pages and Blog under a "Content" drilldown?

A little more broadly: which (and how many) top and second-level items should be in the site management sidebar?

There are many possibilities, below are a few.

Working assumption (6)

current items (Templates, Template Parts) + "stuff"

Styles
Navigation
Templates
Template Parts
Library
Content

Assumptions/Observations

• The WordPress Template Hierarchy could be an intuitive starting point for organizing templates.
• Posts and Pages are natural orderings for navigating both Templates and Content, and could be combined, with UX effort.
• The current homepage is the default thing shown in the Site area.
• The current homepage, somewhat unintuitively, could be a template or a page (+ a template), depending on Settings > Reading.
• 2nd level items could be more complex that just a link, and the top bar could show additional info.
• 7-8 items is on the high side. The current 10 default admin sidebar items (before plugins) have 0 to 8 2nd level items.

Dashboard 2
Posts 4
Media 2
Pages 2
Comments 0
Appearance 2
Plugins 2
Users 3
Tools 8
Settings 7

So here are some opinionated "bests" for 5, 6, 7 items at top level:

Best 5 Top Level Items

Styles
Navigation
Templates
Library
Content

Benefit: Tells a clear short story to a user
Downside: Template Parts under Templates or Library

Best 6 Top Level Items

Homepage
Styles
Navigation
Templates
Library
Content

or

Styles
Navigation
Templates
Library
Pages
Posts

Benefits:

• Either better than Template Parts at top level
• Homepage item could clarify default view

Best 7 Top Level Items

Homepage
Styles
Navigation
Pages
Posts
Archives
Library

Benefit:

• A clear story that maximizes top level
• Aligns to site architecture of existing template hierarchy

The most different from the current, but maybe my favorite.

Possible second-level items

Content (2)
Library (3) with template parts
Templates (6), 4 if Search, Not Found moved to pages

Content

• Posts
• Pages

Templates

• Homepage
• Pages
• Posts
• Search

Library

• Reusable blocks
• Patterns
• Template parts

Expanded Template Hierarchy (6 areas)

Homepage

• Default
• Home
• Front Page
• Page
• Latest posts

Pages

• Default
• Custom Post Types
• User-Created

Posts

• Default
• User-Created

Archives

• Default
• Author
• Category
• Custom Post Type
• Taxonomy
• Date
• Tag

Not Found
Search

[jasmussen]

Taking the latest state of the PR for a spin, and I'd love for us to move towards a state where we can make a decision on what to merge as a first iteration. Here's a snapshot of the current status:

Working well:

• The general layout of the sidebar, which is close to the design Jay has in Figma in dimensions.
• The animation moving in and out of edit mode.
• The scale being applied to contents inside the frame — items still feel clickable in the overview (I know they aren't yet, but that was my main concern).

A few things that remain unclear. One being: I don't think we should show the back button here, it should be present only for menu drilldowns, lest when you click-click-click from a deep nesting you don't accidentally go to the dashboard. I think it's best to have the W menu be the "back to dashboard" affordance:

Details territory, it would be nice if the icons could line up better with the D in "Design". Jay's mockups have them a bit closer:

There's still an open question on how to treat template parts in the browse mode. A starting point might be to just hide the resize handles in this overview mode:

While the animation looks good, I'm not sure about the apperance of the editor bar, mainly because it causes a jump in the content. It's not jarring, to be fair, but this is something to decide on:

Should the animation be a bit faster? I always like for animation to be very fast, never longer than 0.2s.

One big challenge of course is the Edit button, where it should sit. I personally think either of these three options, based on Jay's work, can work:

First and second option are close to what's in the branch now, but require a larger clearance around the frame.

Third option is pretty simple, but will likely work as well, even if it loses some context. This might work better with a wider sidebar, in the PR it's 320px vs. 360px in Jay's mockups.

But ultimately, whether we go one route or the other, I have a feeling this boils down to some of the technical aspects. It's important to consider how the contents of the frame shift from the Templates list, and to the browse view. Right now it's a bit jumpy, and in fact the dimensions of the frame change a bit:

That isn't ideal, and this shifting is something we need to feel pretty good about on the technical level, if the frame is going to become such a large cornerstone of the design. What are our options here for making this feel resilient?

• Does it simplify things if the Edit button sits on the left vs. above?
• Does it simplify things if the frame always has identical clearing, even if large, all around?
• Can the frame be animated when it changes size? Does the way content is loaded inside afford this?

I know these are rather big questions, but they are important to get right before we merge this, and would love also @pablohoneyhoney or @mtias insights.

[jameskoster]

Template parts are looking better in browse view, thanks! There is an issue with the dimensions of the wrapper when you enter edit view though:

tp.mp4

That's particularly important for zoom-out mode scaling and I don't feel like we should be implementing two different ways of scaling the canvas.

I understand, but the problem is that the browser metaphor is broken. For sites that make use of lots of full-width elements the experience will be quite strange. If there's really no way around it on the engineering side then perhaps we should remove the styling on the frame altogether and increase the scale in browse view a bit. This is the result:

frame.mp4

The scrollbar is positioned a bit awkwardly, but the document appears the same in both views which seems very important to me.

[youknowriad]

Template parts are looking better in browse view, thanks! There is an issue with the dimensions of the wrapper when you enter edit view though:

This should be fixed.

[youknowriad]

I understand, but the problem is that the browser metaphor is broken. For sites that make use of lots of full-width elements the experience will be quite strange.

The other solution there is to actually show a different background around the scaled area (like we do in zoom-out mode) which means we'll have the "frame" and a visible background/padding within the frame.

[jameskoster]

Here's how that would look:

frame.mp4

I think the metaphor is still broken. The frame boundary is supposed to be synonymous with an actual browser window. If it's not a 1:1 representation then I'd argue there's no point "painting" the frame at all, and no background would be a better approach.

[jasmussen]

Would it be possible to ship the branch as an experiment to be activated, or does it touch too many pieces in order for that to be feasible?

[jasmussen]

A couple of us from this thread huddled in slack and here are the notes. The main questions were around reaching a baseline for the PR in question that was better than the site editor as it exists today, so that we are able to merge and iterate.

Notes

"Browse Mode"

• “Navigation” as an item in the dark sidebar also navigates the content of the frame, as would a “Content” section.

Is it possible to put this effort behind a Gutenberg experiment?

• Possible, could take a day. Probably don't need an experiment for the whole frame, but maybe for specific things like the edit button, or the navigation structure if we want to keep the flow with the W for a bit.

“Edit” button.

• Since “Edit” is contextual to what you see inside the frame, perhaps it can sit anywhere.
• We can test some things. It could be anchored with “Design”, it exists at that level. If you’re at a different level, like “Navigation”, maybe there’s a plus there to add menu items. It could also be a higher level. But it’s important to consider the edit button as a semantic element that might exist contextually with different behaviors across other sections.

“The frame”

• Most important piece to get right, we can’t get to a good place unless we adress this.
• It’s content only, no header, no sidebar, no inserter, those exist outside the frame.
• The frame is a specific slot where we assign the contents of the skeleton.
• Technically, once we click edit, the canvas expands, and the toolbar and sidebar appear from outside the canvas. The controls are part of the “Design” interface, and when you’re in fullscreen mode, there’s a toolbar that drops from above.
• A content only view might also help with getting the animation right.
• The editor is an experience, so once we’re in a “zoom out frame mode”, the editor doesn’t have any tools: you’re browsing.
• The header with the W at the top doesn’t have any tools. Once you zoom in, the W/Header area shows contextual tools. It’s just that the frame is now occupying the full page. The tools relate to the state that the full page is in, which is fullscreen mode.
• The structure is important, that’s why we put so much emphasis on the animation of the canvas, and the UI items. Where does the UI live, conceptually and in the structure of the thing? If the header is inside the frame, it’s not going to look right.
• A header dropping from the top helps convey this.
• The whole page is an editor, and is aware of it, and interacts with its content. You can edit when zoomed out (such as move the navigation around), it’s just that when you zoom in you get more tools available.

Action items:

• Design a “Templates” subsection of Design. Goal: find out what needs to be “generic” (semantic controls that live in the dark material) and what needs to be local to the view. Does it have a header? Does it show only templates? Does it have a list view that gets loaded when you click “Manage all templates”?
• Questions to answer: what does the frame contain if we drill in? What are elements of the current view that don’t belong inside the frame? Should the sidebar move? That might help clarify what should be generic and what shouldn’t.

[annezazu]

Hi folks. In testing this out ahead of an FSE Outreach Program exploration, I was struck by a few things that felt quite jarring. To quickly summarize:

• The edit button is wildly small and hard to find.
• I'm used to being able to enter the site editor and begin editing directly. There's no warning or clarity why I can't.
• The zooming that happens in browse mode doesn't align with zoomed out mode in a way that feels jarring/strange. I wish there was more consistency.

Here's a video just showing how... strange the experience feels:

zooming.in.out.mov

I know this is a work in progress but wanted to share early thoughts for now.

[annezazu]

As part of the FSE Outreach Program's Site Editor exploration, the following was brought up as a point of concern that ties in with some of my notes above around the current zooming experience:

The new motions may be too much for some folks. At the risk of adding complexity, has there been discussion of the accessibility aspect of these transition effects?

I've seen some discussion in the PR itself but wanted to note this here to be safe.

[jasmussen]

These animations like all others should be subject to the reduce-motion user preference, which should disable them.

[annezazu]

More feedback has continued to come in around the edit button/experience:

The edit button is very small/hard to see – I feel like clicking into the content area should allow me to edit. I kept trying to do this (unintentionally)

My muscle memory made me expect to be able to click on elements to edit them – which I obviously couldn’t do.

I've personally done this as well! It makes me wonder if we need a "double click to edit" UX here too.

[annezazu]

What about being able to double click the canvas window to go into edit mode of the “default” template? As if I had selected a template and clicked the Edit button.

This feedback just came in for the FSE Program Testing Call #19: Running Through Refinements. @jameskoster & @jasmussen curious what you think! The biggest hold up I have mentally is that I know long term browse mode should let you click and see other parts of your site (truly interact) with the edit button being the distinguishing moment when you can edit. I can understand why we might want to preserve true editing until someone selects "edit" if we do allow for a more "live preview" style moving around of the site in time.

[jasmussen]

I think that could be a nice power-user feature to potentially explore, but it would likely need to be an affordance built upon an explicit action found in menus or otherwise. Also to be mindful of, a double-tap on tablets means zoom in some cases.

[annezazu]

Happy to open this as a separate issue but wanted to note three folks saying the same thing as part of the FSE Outreach Program's exploration around this new feature: there needs to be a more visible way to get back to the dashboard.

From @paaljoachim here:

The < Dashboard link should still be present in the new browse mode, as it gives a clear signal that clicking it will return to the Dashboard. Or Atleast have a Hover over the W (site identity) showing the tooltip that says "Return to Dashboard"

And from two folks in the outreach program:

I still think that getting back out to the Dashboard could be more obvious. I’ve been working in it for a while now so I know that clicking the W gets you there, but if I was just encountering this for the first time, I would be looking for a “Dashboard” button or link."

& once more:

Reflecting the sentiment of the previous commenter, it isn’t immediately obvious (to a user new to WordPress, specifically) that the “W” logo is the way to exit the editor."

[annezazu]

Two different folks in the FSE Outreach Program's exploration around this feature noted a desire for breadcrumbs of sorts when you're in this new experience. You can hear it discussed in @paaljoachim video starting here for about 1 minute and otherwise here:

it would be nice to have breadcrumbs indicating what exactly we are editing, as annotated in this screenshot: https://cln.sh/vut5dN

What's the current thinking here? I do think there might be value in emphasizing the breadcrumbs perhaps more. I know we have breadcrumbs at the bottom of the editor but, either way, wanted to note these initial reactions of folks!

Let me know if these need to be issues, @jameskoster! Trying to follow the design discussion since this is still very much a work in progress but happy to open any and all issues.

[jameskoster]

Since we aim to add full browse-ability to the zoomed out frame, I think it would be beneficial to display both the URL and the template name in an address-bar style UI:

This helps user orientation, and to explain the relationship between content and the various templates. Down the road it can also act as a global search allowing super fast navigation to specific items.

[jasmussen]

I'd be happy to try this as a followup to showing the Edit button right aligned in the "Design" slot.

[jameskoster]

Yes I don't think it needs to block the PR.

[annezazu]

Agreed on all fronts -- this looks like a great iteration and let's get the PR shipped for now :)