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

Site Editing: UI Parity #21245

Closed
15 of 17 tasks
mtias opened this issue Mar 29, 2020 · 15 comments
Closed
15 of 17 tasks

Site Editing: UI Parity #21245

mtias opened this issue Mar 29, 2020 · 15 comments

Comments

@mtias
Copy link
Member

@mtias mtias commented Mar 29, 2020

These are some of the features that are lacking in edit-site at the moment compared to regular editor.

@vindl
Copy link
Member

@vindl vindl commented Mar 31, 2020

Full screen and spotlight modes.

Just a note that Full screen mode was added in these PRs: #20691, #21006.

@vindl vindl added this to Inbox in Full site editing Mar 31, 2020
@vindl
Copy link
Member

@vindl vindl commented Apr 24, 2020

Device preview added in #21309.

@vindl vindl moved this from Inbox to In progress in Full site editing Apr 24, 2020
@MichaelArestad
Copy link
Contributor

@MichaelArestad MichaelArestad commented May 4, 2020

Noting this here (instead of the above closed issue): I would expect parity on the more menu options shown here:

image

@noahtallen
Copy link
Member

@noahtallen noahtallen commented May 21, 2020

PR up for top toolbar and focus mode in #22537

@noahtallen
Copy link
Member

@noahtallen noahtallen commented May 22, 2020

Pulling a discussion out of: #22539 (comment) for more visibility. cc @youknowriad & @epiqueras

For the time being, we have accepted that duplicating some code between edit-post and edit-site is acceptable. We don't want to make an abstraction too early which doesn't make sense in the long run. However, when looking into porting the "tools" section of edit-post into edit-site, I realized there is a significant amount of code to copy over.

For two reasons, I wonder if we should not duplicate some of this stuff until we come up with a better abstraction:

  • The amount of code is quite large, particularly as relates to the block manager, keyboard shortcuts, and all of the UI options. And all of this code needs to be essentially duplicated and have the same behavior. (So obviously, it makes no sense at all to duplicate it in the long run.)
  • Are any of these features really important for us to have this early in development? Things like managing keyboard shortcuts and blocks are tangential to the FSE experience.

In the future, since we would need to un-duplicate it anyways, I think it would mostly just be wasted time.

This doesn't apply to everything. For example, focus mode and the block toolbar in the header are both primarily implemented in the block-editor package, so the majority of the code is reused between edit-site and edit-post anyways.

Additionally, the code editor will need to be updated to work better with multiple entities.

But some of this other stuff seems like a lot of work for not a lot of benefit at the time being.

This leads me to wonder how much of the "basic UI parity" features should be duplicated before we come up with a good abstraction. I don't think "all of them" makes sense because there would be so much to basically just copy over and hook in. And then we have two copies of everything floating around and we aren't any closer to having a better abstraction.

@epiqueras
Copy link
Contributor

@epiqueras epiqueras commented May 22, 2020

A @wordpress/editor-configuration or @wordpress/editor-settings package makes sense now.

@vindl
Copy link
Member

@vindl vindl commented May 25, 2020

Are any of these features really important for us to have this early in development? Things like managing keyboard shortcuts and blocks are tangential to the FSE experience.

I don't think they are that important at this stage. And I agree with you that it would be a waste of time if they are duplicated now.

@noahtallen
Copy link
Member

@noahtallen noahtallen commented May 27, 2020

This looks related: #21430

@bobbingwide
Copy link
Contributor

@bobbingwide bobbingwide commented Apr 26, 2021

@mtias Perhaps you could update the initial checkbox item "keyboard shortcuts" in the initial comment to reflect the fact that there have been at least two separate issues raised and closed without a fix or any sign of a plan to fix them.
I would suggest either attaching #30294, since it's still open, or re-open the closed issues until they have been fixed.

@annezazu
Copy link
Contributor

@annezazu annezazu commented Nov 15, 2021

I see this checked off currently:

help link (Edit Site: Add basic "tools" menu #22539 @noahtallen)

However, when I look at the experience today, I only see the option to export items but don't see a specific help option in place. Since FSE is so new, it would be advantageous to have a link to support docs built into the interface. Is this something that can be added ahead of 5.9?

@Mamaduka
Copy link
Member

@Mamaduka Mamaduka commented Dec 28, 2021

I started working on Keyboard Shortcut help modal. Unfortunately, it's a bit late for the 5.9, but we should backport it into a minor release.

@Mamaduka
Copy link
Member

@Mamaduka Mamaduka commented Dec 28, 2021

@annezazu, do we have a documentation URL for the "Help" button?

@annezazu
Copy link
Contributor

@annezazu annezazu commented Dec 28, 2021

This will eventually be the URL: https://wordpress.org/support/article/site-editor/ This will provide a similar experience as the Post Editor which links to https://wordpress.org/support/article/wordpress-editor/.

@carolinan
Copy link
Contributor

@carolinan carolinan commented Dec 29, 2021

@annezazu I'm out of the loop because of the holidays, does that mean the project agreed to keep using the term "site editor" ?
Is it still only going to be called "Editor" under appearance?

@annezazu
Copy link
Contributor

@annezazu annezazu commented Dec 29, 2021

It's only going to be called "Editor" under Appearance but I'm not quite sure how else to position this. If we reuse the current https://wordpress.org/support/article/wordpress-editor/ doc and add in FSE related content, it'll likely confuse many of the folks who are just using the Post Editor. The best middle ground I could provide was by creating a separate doc for the Site Editor since that matches what was done with the template editor. Open to ideas/thoughts though around how best to proceed here :) In time, I imagine all of this will turn into just the WordPress editor but, for now, we need some in between solutions. Here's the documentation tracking issue here: WordPress/Documentation-Issue-Tracker#93

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
Full site editing
  
In progress
Development

No branches or pull requests

9 participants