search

WordPress / gutenberg

The Block Editor project for WordPress and beyond. Plugin is available from the official repository.
https://wordpress.org/gutenberg/
Other
10.46k stars 4.18k forks source link

Re-Introduce Content Editing in the Site Editor #44461

Closed jameskoster closed 1 year ago

jameskoster commented 2 years ago

Visual

pages

Tasks

jameskoster commented 2 years ago

One option (which overlaps with Browse Mode) would be to present the web site in a frame upon entering the Site Editor (a concept first introduced in https://make.wordpress.org/design/2022/06/13/thinking-through-the-wordpress-admin-experience/). The frame could feature a dynamic address bar, allowing folks to search for content to display and edit:

https://user-images.githubusercontent.com/846565/192272035-e59ce52c-e642-4910-9d4d-2d017c32655f.mp4

One problem with the previous drill-down approach was the fatigue it caused when navigating deep into content trees. The dynamic address bar solves this. Another benefit is the obfuscation between content and some templates, for example it seems reasonable to surface the 404 template if one were to search for it here.

jasmussen commented 2 years ago

I like that minimal browse mode for allowing you to choose content to edit, if we pair it with an explicit "Templates" item in the sidebar for when editing that is your intent.

The bigger win would be to not drop you directly into editing your "Home" template, rather to allow you to make a choice first in the open-by-default sidebar.

Should we try and prototype a minimal version of that? Someting like:

This would let us still have a generic template list as it exists today, and could be a small step towards true browse mode where links in the viewport actually become clickable.

What do you think?

jameskoster commented 2 years ago

The bigger win would be to not drop you directly into editing your "Home" template

100%. I think it's vitally important that we place template editing / management at an appropriate altitude in the UX. It's over-emphasis one of the biggest overall sources of confusion in the site editor.

Should we try and prototype a minimal version of that?

That's certainly an option, though I find the "Site" button a little awkward, and it's quite buggy (https://github.com/WordPress/gutenberg/pull/42807, https://github.com/WordPress/gutenberg/issues/36821).

We might place Templates in a drill-down instead. That is aligned with the de-emphasisation of template management mentioned above, and would eliminate the need for the buggy "Site" button. As an added bonus it'd create space for us to delineate different template (and part) types, which is something that has come up in https://github.com/WordPress/gutenberg/issues/42325.

Here's a demo:

https://user-images.githubusercontent.com/846565/192831898-57fdeb5d-672f-4b12-99f1-e43a1f59fa87.mp4

If that leap is too large, then your suggestion sounds like a good middle-ground to me.

jasmussen commented 2 years ago

I like the idea that you see the viewport and are able to click "Edit" to edit the content.

I think it's too early to put Templates inside the "Library", I would intuit mainly custom stuff be placed there. Which yes, arguably you can create custom templates, but it still feels as stretch, so to reduce drilldown we should probably keep templates top level for now, IMO.

jasmussen commented 1 year ago

As a small update, a navigation interface was recently merged:

nav

The feature isn't yet implemented, but clicking a navigation item in the sidebar on the left, is also meant to load that page in the view on the right. It's a nascent taster of "browse mode", as the view on the right should similarly be navigable. It also doesn't preclude a separate "Content" drilldown to let us search pages, posts, or otherwise. But nevertheless, it's a small status update for this one.

fabiankaegy commented 1 year ago

I mentioned this in today's Core Editor Chat, but I wanted to also share it here for the record.

Given how close we are to the feature freeze of 6.2, introducing this without the ability to test it in a few Gutenberg plugin release cycles would be rushing it.

I really want this feature to be available asap. But less than a week before the feature freeze doesn't leave much time for testing & fine tuning the experience.

Happy to be proven wrong though if anyone disagrees.

ndiego commented 1 year ago

Thanks @fabiankaegy, I have moved this to "In discussion, needs decision" on the board.

cc @Mamaduka @ntsekouras

jameskoster commented 1 year ago

To expand on @jasmussen's earlier comment, one idea that has bubbled up in design discussions around https://github.com/WordPress/gutenberg/issues/36667 is that a document-level panel in the drilldown menu area could be a useful design pattern.

Screenshot 2023-02-06 at 11 32 45

Clicking a page in the Navigation panel does two things:

  1. Updates the 'frame' to display that page
  2. Drills into a panel containing meta controls for that page

To begin with the panel can start simple – perhaps it only contains the title, publish date, and Edit button. But as demonstrated in the diagram above, in the future we can expand this to include high-level edit capabilities such as changing the template, featured image, etc.

By allowing the document-level panel to contextualise what is visible in the frame, the burden on the 'site hub' is lessened so that it can probably revert back to displaying the site title.

If this pattern works well we can use it in other sections like Templates. A template drilldown could (for example) offer quick ways to change the header / footer, or select a pattern for the entire template, without having to engage the 'full' editor.

cc @youknowriad

Mamaduka commented 1 year ago

@jameskoster, now that #47387 is merged and #47777 is in progress. What are the remaining items for this feature?

jameskoster commented 1 year ago

I think the final piece required to close this issue will be a method of accessing content that is not represented in the main navigation. For example editing an individual post. I've seen 'command palette' concepts shared elsewhere, e.g:

https://user-images.githubusercontent.com/846565/217860932-12d9baff-32d5-454b-94bb-043077503205.mp4

But I don't know if we're 100% ready to commit to that yet.

Mamaduka commented 1 year ago

The command bar would be cool but also as a general assistant for the editors 🤩

noisysocks commented 1 year ago

Another remaining item is that users should be able to click on links within the preview on the right hand side, yeah?

jasmussen commented 1 year ago

Another remaining item is that users should be able to click on links within the preview on the right hand side, yeah?

Possibly/probably in some form eventually yes! During 6.2 development, we shelved this aspect of browse mode in favor of title plus edit icon in the left navigation, with the frame preview as one big additional edit button. I do see URL navigation returning at some point, whether it's like originally envisioned, or perhaps when holding ⌘. But after the refocus, that aspect should probably not hold up this issue.

noisysocks commented 1 year ago

Assigning this to @SaxonF and I since we have been privately working on some ideas for clarifying the relationship between templates and content.

jameskoster commented 1 year ago

Here's a WIP design for a "Pages" panel in the Site Editor, somewhat extracted from https://github.com/WordPress/gutenberg/compare/try/pages-list:

Screenshot 2023-05-05 at 16 14 59

One of the main things to discuss is the name of this panel. "Pages" introduces a bit of awkward duplication with the equivalent item in wp-admin. Alternative options could be "Site Structure", "Content".

cc @WordPress/gutenberg-design

SaxonF commented 1 year ago

@jameskoster I've spun off https://github.com/WordPress/gutenberg/issues/50418 as a follow up to this issue for adding general templates to the list

youknowriad commented 1 year ago

It seems no one is working on the "pages" navigation item in the site editor. (The design shared by @jameskoster here https://github.com/WordPress/gutenberg/issues/44461#issuecomment-1536430171 ). Am I right? I'm going to bootstrap that part quickly (without changing the "edit" mode), just adding the sidebar.

noisysocks commented 1 year ago

I listed the remaining pieces of work in the description so as to make this more of an overview issue.

ramonjd commented 1 year ago

Display preview in the frame when hovering mouse over a page. Also do this for templates and template part Hovering a page will show that page as a preview in the Frame

Has there been any elaboration on these ideas?

My first thought was to reach for the block preview popover, similar to how we preview blocks in the inserter or block styles, but then I realized the intention is for the preview to display in the main editor window. Is that right?

I've been poking around the sidebar components, and I'm scratching my beard trying to work out the best way to do it.

Let's say we want to load a page in the editor "frame". We can change the document.href to something like /wp-admin/site-editor.php?postType=page&postId=31, but useSyncPathWithURL() kicks in and navigates to the single page pane in the sidebar. Here's me hovering over the items with no other changes.

2023-05-15 14 23 22

It seems like we'd have to rewire the sidebar routing synching, breaking it in the process.

For example, if we change the URL to point to a single page (in order to load it in the editor) from the pages list panel but prevent navigation to the single page panel (like we'd have to onHover) we're breaking the routing for that panel.

Similarly when I hit refresh on /wp-admin/site-editor.php?postType=page&postId=31, I expect the sidebar panel to always open to the singe page panel so that behaviour would have be preserved.

I might be wrong and chasing my tail here. 😄 I'm just dumping my thoughts for now.

Perhaps there's a way using the EditCanvasContainer

SaxonF commented 1 year ago

@ramonjd I made a little POC a while back that uses something similar to your suggestion

The issue is performance. It would be great if we could preemptively fetch a certain number records in anticipation of hover.

ramonjd commented 1 year ago

The issue is performance. It would be great if we could preemptively fetch a certain number records in anticipation of hover.

Thanks for sharing that @SaxonF - Yeah, I had doubts about its snappiness. I'll take a look. Cheers

youknowriad commented 1 year ago

To be honest, I'm personally not convinced why we should show pages on "hover". It's a weird behavior since one might think, he can go and click the page as it's visible but as soon as you leave the page itself, you'll be back to the home page causing frustration. What's the reasoning for this behavior, it seems very uncommon.

ramonjd commented 1 year ago

To be honest, I'm personally not convinced why we should show pages on "hover". It's a weird behavior since one might think, he can go and click the page as it's visible but as soon as you leave the page itself, you'll be back to the home page causing frustration. What's the reasoning for

I've been playing around with it and have come to the same conclusion. The work involved to get it to the point where we'd be able to load full templates and page content (and their styles) in unison with mouse movements is, in my opinion, not a great investment.

If it was something that we desperately had to do, then I'd speculate that we'd want to have an alternative way to load the previews — separate to the editor — so we could better manage preloading and so on.

annezazu commented 1 year ago

I see needs design has been removed. Adding this as needs dev and moving it forward in the respective project board. Feel free to change back as needed!

SaxonF commented 1 year ago

@youknowriad one of the main benefits of the side by side / frame paradigm we've adopted here is it gives us a way to quickly preview content without having to dive in and out. Since we now drill down on click we aren't making full use of that paradigm. What is the benefit of side by side view vs a table if we don't have a way to preview? We might as well just take people to a table. MacOS finder offers the ability to switch between view types because they are each ideal for a certain use case.

youknowriad commented 1 year ago

I can't speak about the benefits of the side by side view, but I'm talking more about the UX feeling when hovering these menu items, I don't really expect what's on the right to change, especially since I can't interact with it. Anyway, it would be cool to get some more testing on the related PRs to experience it and see how it feels. I just now that it feels very confusing to me.

SaxonF commented 1 year ago

That's fair. @ramonjd disregarding performance, if we could get a demo branch up to play with that contains just hover I think that would be worthwhile. We can even just copy the code from the branch I linked to above.

tellthemachines commented 1 year ago

I agree that the hover thing feels very awkward. I wonder, if the problem is finding a way to view contents without drilling down, do we really need the detail view for each page/template? This

Screenshot 2023-05-16 at 10 07 08 am

has no useful information.

If instead of showing the detail view, clicking on a page or template just showed it in the main area while keeping the list of pages/templates in the sidebar, navigation would be so much easier.

ramonjd commented 1 year ago

disregarding performance, if we could get a demo branch up to play with that contains just hover I think that would be worthwhile. We can even just copy the code from the branch I linked to above.

No worries at all 👍

Here's something folks can play around with get a feel for whether it works or not:

As for the implementation I'd say we'd need to find a different way given the way it affects the browser history.

jameskoster commented 1 year ago

Just a note to say I've updated the OP to include the latest designs, and added a couple of tasks to the list.

jasmussen commented 1 year ago

We're discussing a bit in https://github.com/WordPress/gutenberg/issues/49597#issuecomment-1553037566, but I'm not too sure about the "Manage" links in the title. It doesn't seem like a pattern that will scale to translations. Everything else looks good to me.

jameskoster commented 1 year ago

I think the shortcut is useful as the page list in the panel is not exhaustive.

Perhaps it can be a contextual item in the command palette (related: https://github.com/WordPress/gutenberg/issues/50407)? What do you think @richtabor?

richtabor commented 1 year ago

Perhaps it can be a contextual item in the command palette (related: https://github.com/WordPress/gutenberg/issues/50407)? What do you think @richtabor?

I’m not quite following?

jameskoster commented 1 year ago

Apologies. I was suggesting that "Manage pages" could be a contextual shortcut in the command palette, when you're viewing the Pages panel in the Site Editor. It would link to wp-admin page list.

mtias commented 1 year ago

It looks like the main work here is done, the follow ups are either not strictly related (add new page modal) or further improvements. I'm going to close this. Let's make sure to open issues for things that are relevant and don't have issues open yet.

porg commented 1 year ago

🤔 This issue is closed? Really?

I'm wondering because I tested Gutenberg 16.1.2 today, but saw no possibility to edit a page and template combined (as it was possible til until 15.9.1)

So where is that possibility now?

noisysocks commented 1 year ago

Based on feedback it was very confusing for users to edit both template and page at the same time hence the split. I appreciate it's useful for theme authors to preview with real content though. https://github.com/WordPress/gutenberg/issues/28466 looks like a good way to address that.

porg commented 1 year ago

Thx, had followed up there meanwhile.