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

Widget-block Screen in wp-admin #13204

Closed mapk closed 4 years ago

mapk commented 5 years ago

As noted in the Phase 2 post:

The first step for phase 2 will involve upgrading the widgets UI to incorporate a modern block editor that is consistent with how you edit pages and posts in Gutenberg to create a clear, consistent editing experience across different areas of your site.

widgets.php would become something more like this, which is an early sketch, but you can see that all of these widgets are represented as blocks.

widgets-new-1024x529

and split screen of changes:

widgets-half-1024x529

We'll need to determine if these mockups are the right solution. Let's dig in!

joyously commented 5 years ago

I see several problems with showing only one widget area at a time.

Is there any need to render the content? I think it's grand to have the site configuration as it currently is on the widget page. I can easily see all the widgets and rearrange them. I don't have to be bothered by their actual content obstructing the view of the configuration. If I want to see how they render, I can use the Custimzer, where my changes are not published until I'm ready, and I'm limited to one widget area at a time, and can't move widgets between areas.

ZebulanStanphill commented 5 years ago

I see several problems with showing only one widget area at a time.

  • It's difficult to move things from one area to another.
  • It's difficult to get a sense of what is already on the site when you can only see one at a time.
  • It looks too much like editing a page (user confusion).

Good points, @joyously. I guess the best way to move forward in the short-term is indeed having all the block areas edited from a single page.

In the future, I think the same thing should still be possible, but not quite in the same way. You should be able to edit multiple block areas that are all shown on the same page template via page template editing... the block areas would be reusable blocks which could be edited right there (or in a standalone instance of the editor if desired), just like how reusable blocks already work. This would solve all of the issues mentioned above, while also keeping the WYSIWYG benefits of the Gutenberg editor. At this point, there would be no need for a page like the current Widgets page. But obviously, we are still far from that point.

Is there any need to render the content? I think it's grand to have the site configuration as it currently is on the widget page. I can easily see all the widgets and rearrange them. I don't have to be bothered by their actual content obstructing the view of the configuration.

One of the design principles of Gutenberg is that unselected blocks show a preview that should look just like the front-end, and selected blocks should be optimized for editing. So ideally, the content should never obstruct the configuration. Unfortunately, the block equivalents of the existing widgets are almost perfect examples of what not to do.

Unlike the Paragraph or Heading block, you don't edit the content of something like the Latest Posts block directly. Unfortunately, this has resulted in most of the important controls being thrown in the inspector, which is designed for secondary/advanced options. I think that blocks like it should be revised to show the important controls in an overlay on top of the content preview when selected, or else the preview should disappear entirely when the block is selected. There's technically nothing stopping the selected, editable form of a block from looking completely different from the unselected form.

Additionally, to make re-ordering blocks easier, I think the Block Navigation menu should be re-implemented as a plugin sidebar and allow drag-and-drop reordering (plus maybe even removal) of blocks from its UI. See #11408.

jasmussen commented 5 years ago

Maybe the solution here is to drop the top bar completely from this screen?

I can imagine a future where widgets are managed primarily from the editor itself. By keeping the top-bar, we both keep the recognizability of the editor — you learn a single interface — and it forces us to look at any accessibility issues at the root and fix them holistically instead of fix them on a per-screen basis, fragmenting the interface architecture.

melchoyce commented 5 years ago

I really appreciate you adding that mockup, @ZebulanStanphill! Definitely helps me visualize.

One thing I'd note is that we've found in previous user testing (pg. 23) is that people don't notice the publish bar if it's on the bottom of the screen. Even when reminded about it, folks forgot it was there. Some thought it looked like browser chrome. I can see that problem being intensified on mobile web, where bottom-docked ads are prolific.

afercia commented 5 years ago

we've found in previous user testing (pg. 23)

Sorry, not willing to argue but it's a fact the user testing didn't include persons with accessibility needs, for example keyboard users, screen reader users, and users with a limited vision field.

The position of the Save button in Gutenberg was already discussed months ago, with no consensus. I realize that visually some users prefer the button at the top. However, in a linearized navigation experience, the current button position is less than ideal because it forces users to tab backwards through the whole interface.

It's a known problem, even before Gutenberg because the same pattern is used in the Customizer.

In a logical flow, in any web application the saving action is at the end of the flow. I'm not saying the publish bar at the bottom is a solution, but this is still a problem that needs a good solution for all users.

mapk commented 5 years ago

By keeping the top-bar, we both keep the recognizability of the editor — you learn a single interface — and it forces us to look at any accessibility issues at the root and fix them holistically instead of fix them on a per-screen basis, fragmenting the interface architecture.

@jasmussen This is fair and I agree with a holistic approach toward a11y. My hopes is that we don't invest a lot of time on this screen which is likely to deprecate in the future. And the a11y around the top bar should definitely have an issue assigned.

I did end up including the top bar in my prototype, but just eliminated a lot of the functions that may not work on this screen. Do you think this was a good solution, or do you feel the other parts that were eliminated are useful here?

jasmussen commented 5 years ago

I did end up including the top bar in my prototype, but just eliminated a lot of the functions that may not work on this screen. Do you think this was a good solution, or do you feel the other parts that were eliminated are useful here?

We should absolutely remove any buttons there that don't make sense for the widget screen, for sure.

ZebulanStanphill commented 5 years ago

@melchoyce In addition to what @afercia said, I would say that part of the problem with the bottom bar in the Crazyhorse Demo is that it really does look like a pop-up or browser chrome:

image

It is using a background color that clashes with the rest of the editor, and it overlays even the navigation on the left. Both imply that it is not part of the editor at all, and therefore not relevant. It is also definitely too tall. Contrast this with the current top bar in Gutenberg, which definitely feels connected to the rest of the editor.

I can see that problem being intensified on mobile web, where bottom-docked ads are prolific.

I really don't see this being a problem. Lots of apps put controls in a bar at the bottom of the screen, e.g. Spotify, Twitter, and Instagram. Even Gutenberg Mobile already puts several of its controls at the bottom: untitled

Given the vast differences between the Crazyhorse Demo and Gutenberg, I'd say the two are hardly even comparable. But thanks for pointing out that old user testing anyway; I was not aware of its existence before.

@mapk

...I agree with a holistic approach toward a11y. My hopes is that we don't invest a lot of time on this screen which is likely to deprecate in the future.

This is the big issue. We can't drop blocks into the existing Widgets page design. We shouldn't make a separate UI design just for the new Block Areas page. But since the post editor still has some major flaws, we can't just re-use it either. So ultimately, the Widgets page overhaul is blocked by the post editor needing to be improved.

And the a11y around the top bar should definitely have an issue assigned.

I agree.

@jasmussen

We should absolutely remove any buttons there that don't make sense for the widget screen, for sure.

For a page that shows multiple block areas at once, most of the controls in the top bar no longer make sense. Only the Settings sidebar and More Options menu would still make sense. Additionally, plugins like Yoast SEO may no longer work when applied to a screen with multiple block areas, so perhaps plugins will have to opt-in to support the Block Areas page?

If we updated block areas to support drafts, scheduled updates, and undo/redo, then "Undo", "Redo", "Save as Draft", and "Update" buttons could appear below each block area. But given that in the long-term, the Block Areas page will probably cease to exist entirely when page templates come around, I'm not sure it is worth implementing that extra functionality.

Additionally, I think that the ability to edit block areas individually should be added anyway, in order to allow for a fallback way to edit block areas, where plugins like Yoast SEO that only make sense in a single block area editor could be used if desired.

mapk commented 5 years ago

This is the big issue. We can't drop blocks into the existing Widgets page design. We shouldn't make a separate UI design just for the new Block Areas page. But since the post editor still has some major flaws, we can't just re-use it either. So ultimately, the Widgets page overhaul is blocked by the post editor needing to be improved.

I understand the concern and agree with just about everything here. However, as we work further to improve the a11y in the topbar and Inspector, I believe we can still move forward with the prototype laid out in this comment simultaneously:

https://github.com/WordPress/gutenberg/issues/13204#issuecomment-459175233

@youknowriad, do you think we can begin dev work around this?

youknowriad commented 5 years ago

Not quite yet, this PR #13088 is a requirement here and we'll begin explorations as soon as it lands.

mapk commented 5 years ago

Also wanted to note that an issue has been created [#13663] to work on the a11y issues discussed here.

gschoppe commented 5 years ago

One major concern I have is the single save button and single draft/publish functionality. Widget areas are spread across the site on many different pages, and have many different concerns. It seems much more logical to be able to deploy changes to them individually.

This re-imagining of widget areas would be a great time to properly isolate them enough that users could schedule changes to each widget area separately.

joyously commented 5 years ago

I was just answering a question in the support forum about how to better move Inactive widgets to sidebars after a theme switch (using an iPad), and I realized that this Widgets page has a Screen Option of an accessibility mode. Using that, it shows only one widget at a time, but gives the choice of which sidebar to put it in, similar to what you get when you click on a new widget without accessibility mode. I wanted to make sure others were aware of this, so it doesn't get lost in the redesign.

StaggerLeee commented 5 years ago

How about to open block settings in modal box, the same modal code used in Gutenberg ? Would it complicate to much for accessibility.

Personaly I think you would make huge mistake if you try to replicate design and look of pure Post edit screen, for widgets. You would make much problems for yourself in the future.

tomjn commented 5 years ago

For reference, is this the UI I should be shmushing into Frontenberg during phase 2? :)

mapk commented 5 years ago

Yes, @tomjn, this is the UI: https://github.com/WordPress/gutenberg/issues/13204#issuecomment-459175233 but I fully expect bits to change as we go into development, especially in relation to the saving of individual widgets-blocks.

tomjn commented 5 years ago

that's ok, just make sure that the admin page itself is nice and modular so that it's not a nightmare to get running on the frontend, that way you can do as you please without it being rewritten every version

talldan commented 5 years ago

Adding a note here that a trac ticket was raised pointing out an issue when different users concurrently edit widgets, proposing a locking system: https://core.trac.wordpress.org/ticket/12722

It might be preferable to make sure the new widget screen supports a locking solution.

jasmussen commented 5 years ago

Adding a note here that a trac ticket was raised pointing out an issue when different users concurrently edit widgets, proposing a locking system:

Worth noting that although the following ticket is about collaborative editing using WebRTC, the a lot of ideation and design has gone into the process, and the concept is the same: locking a block to the user editing it. Might therefore be worth looking at that UI for reference ideas: https://github.com/WordPress/gutenberg/issues/1930#issuecomment-333455412

jorgefilipecosta commented 5 years ago

I'm sharing a simple comment that summarises the PR's of the main remaining tasks to get block editor for widget areas:

Merging the 3 PR's that reference each other in a chain allows us to have an end to end demo of the block editor for the widgets screen.

In Parallel we need other improvements to make blocks work as expected in the widgets screen.

Remove wordpress/editor usages from the core blocks (wordpress/editor is not available in the widgets screen).

Fix UI problems that make the screen not work as expected or that make the screen have a suboptimal experience.

Other UI problems are affecting the widgets screen, for which a solution is not yet implemented. The major problems are:

jorgefilipecosta commented 5 years ago

Given that some time passed since the last widgets work update I'm going to share a new one containing the developments since the last update. The PR's that connect the widgets endpoint with the widget screen were merged and the PR that renders block in the front widget area of a website was also merged. The screen still provides a suboptimal experience and many enhancements are in progress.

Merged PR's (related to the main screen work): https://github.com/WordPress/gutenberg/pull/15015, https://github.com/WordPress/gutenberg/pull/15074, https://github.com/WordPress/gutenberg/pull/15651

A PR that allows the legacy widget block to reference an existing widget was proposed https://github.com/WordPress/gutenberg/pull/15801.

Legacy widgets still don't work as expected on the widget screen for that we need to make sure we can land user server-side render component on that screen https://github.com/WordPress/gutenberg/pull/15635 and we need PR previous referenced https://github.com/WordPress/gutenberg/pull/15801. Both PR's are pending a review/re-review.

Regarding the work to remove wordpress/editor usages from the core blocks: https://github.com/WordPress/gutenberg/pull/15572 was merged. https://github.com/WordPress/gutenberg/pull/15635 is pending a re-review and I will soon update https://github.com/WordPress/gutenberg/pull/15521 to address the reviews.

Regarding the work to Fix UI problems that make the screen not work as expected or that make the screen have a suboptimal experience: https://github.com/WordPress/gutenberg/pull/15472 was closed because we updated code in other PR that fixes the root cause of the problem. https://github.com/WordPress/gutenberg/pull/15470 is in discussions and is pending a decision.

mapk commented 5 years ago

One major concern I have is the single save button and single draft/publish functionality.

This is definitely a rising concern. I'll explore this more and look at moving this button to be Block Area specific (mockups soon to come). I don't think it's necessary to move to actual blocks.

jorgefilipecosta commented 5 years ago

Another update. The short term project board is available at https://github.com/WordPress/gutenberg/projects/27.

We merged another two important PR's https://github.com/WordPress/gutenberg/pull/15521, https://github.com/WordPress/gutenberg/pull/15396

PR's that need reviews

The next PR with higher Priority is https://github.com/WordPress/gutenberg/pull/15801 which when merged will allow legacy widgets to be used in the widgets screen.

https://github.com/WordPress/gutenberg/pull/15548 is practically ready and needs final approval.

https://github.com/WordPress/gutenberg/pull/15948 was updated and needs final approval too.

Some problems /potential enhancements were found in the PHP code, and two PR's were submitted. It would be some additional eyes on them: https://github.com/WordPress/gutenberg/pull/15981 https://github.com/WordPress/gutenberg/pull/15983

Props to @TimothyBJacobs for doing an initial review to one of these PR's.

Pending updates/discussion

https://github.com/WordPress/gutenberg/pull/15635 was discussed, and it seems we arrived at a possible solution. I liked the suggestion provided by @gziolo of having a ServerSideRenderProvider; I'm going to implement it in the next hours.

https://github.com/WordPress/gutenberg/pull/15470 @aduth provide an alternative idea exposing a new component that includes the BlockEditorProvider but also some artifacts expected from a block editor, e.g., the writing flow. I guess if no one was any concern regarding that approach the best path is implementing that component and update https://github.com/WordPress/gutenberg/pull/15470 to use it.

Other updates

https://github.com/WordPress/gutenberg/pull/15988 proposed by @aduth will unblock the popover positions problem on the widget screen I will review it in the next few hours.

ellatrix commented 4 years ago

This issue hasn't been active in a year. Is there another overview issue for the widget screen?

mapk commented 4 years ago

I don't think so, @ellatrix. If you'd like to close this, we do have the Project Board that has a list of issues as well.

paaljoachim commented 4 years ago

It would be nice to keep this old issue open as it also links to the Project Board. It can also be updated when someone has the time to go back to this issue again.

ellatrix commented 4 years ago

Ok, since there's no movement on the project board and no movement on this issue, I'll remove it from the WP 5.5 board.

jcklpe commented 4 years ago

@ellatrix  I'm unclear on the status of this feature. Is there still plans to convert over the widget sidebar stuff to using Gutenberg blocks?

paaljoachim commented 4 years ago

All the PRs Jorge mentioned here: https://github.com/WordPress/gutenberg/issues/13204#issuecomment-499078467 Have been merged.

Hey Aslan. @jcklpe

The status of the feature is that no one has worked on the Widgets screen in wp-admin for a long time, so it is removed from the WP 5.5 project board. It does not mean it will not be worked on, only that it is not a priority for 5.5.

draganescu commented 4 years ago

I will close this big issue as today it only stands for historic documentation.