Proposal for a more intuitive add block button

[davisagli]

Here is a prototype for a more intuitive add block button, which fixes #682. Here's a screencast showing how it compares to the status quo (sound on):

https://user-images.githubusercontent.com/49014/199147930-dd0964bb-ca3b-42b8-a349-10efd539efef.mov

Details:

• The add button is now shown below any selected block, instead of only at the left of empty text blocks. This provides a more obvious way to add a block between existing blocks, even if the user doesn't know that the Enter key does this.
• The button is also always shown below the last block, even if it isn't selected, to make it extra obvious how to add a block at the bottom of the page.
• The button is centered horizontally. This avoids the problem with it falling out of the viewport at some widths, and also keeps it well clear of the delete button.
• Adding text blocks with the Enter key still works as before.
• Clicking the add button on an empty text block will replace that block instead of adding below it, to help avoid leaving empty text blocks around accidentally.
• In terms of implementation, the button is added in the EditBlockWrapper, so it should work regardless of block type. It's also positioned relative to the EditBlockWrapper. I tested with a project that has customized the block padding and margins, and it still looked fine.

I'm interested in feedback on whether this is desirable and whether there are edge cases I overlooked. If people are generally in favor, I'm happy to continue the work to update the tests and such.

(I'm aware that the Quanta design also includes a new block add button. This is my attempt to borrow the best parts of that idea without tying it to the rest of Quanta, and also to think through some details that aren't covered in that design like how to make the button work in between multiple blocks without messing up the spacing.)

[sneridagh]

My 5c, with the release manager hat on:

When we started Volto 16, we knew that it was going to be Plone 6 final. So we envisioned this release as "the one with slate" and bugfixing release with these goals in mind:

• It will be breaking but without any hard compromise (except the slate one, which in turn, is a big one).
• It will not have any big barrier that could prevent any early adopters sites built in previous versions of Volto to go to Plone 6.
• It will not present any substantial visual change (as in theming) that could break existing themes.

When David came with these proposal, I had to admit that I was +1 to include it in 16 without any further concerns. However, reviewing and writing down again the main goals we had for 16, I admit that it's a hard one to swallow. Since it's a substantial change on UX and how editor users interacts with content, and merging this at the last minute before RC happens without proper real-life and battle testing it, seems wrong to me.

So David came up also with the experimental flags, which allows us to have an scape hatch with this kind of situations. To be honest, I like it a lot. Other frameworks like Next.js are doing it (even Razzle did it in the past). The good thing is that by using them, we could continue releasing all the improvements under 16 without having to move to canary for testing it.

So my proposal is that we don't adopt this change lightly and we take our time to test it properly. Then after this cautionary time passes then we promote it to default, in Volto 17 (since it's a breaking) and then release it along with Plone 6.1 (which will happen much earlier than we are used to). This will give us time to adjust and improve it as long as we receive feedback from our users and projects.

I know that this could upset people, but we have to make the cut at some point, and 16 is already due since a long time ago and Plone 6 needs to fly now.

[davisagli]

@sneridagh I am fine with whatever you decide as the release manager. Did I understand correctly that you are planning to merge it for 16 (with the setting turned off)? Because until it is merged and released, I'm not sure how further testing can happen in the context of real projects.

If I understood that right, then I think it is ready.

[djay]

@sneridagh what usability testing has plone 6 undergone?

[djay]

@sneridagh @davisagli @tiberiuichim @ericof I don't think anyone is upset. and that is the wrong way to make these decisions in anycase. It personally doesn't affect me. I can tell me clients to avoid these bugs and we patch make other fixes in our builds anyway.

UX is not a design you get done once but a continuous process of actively looking for feedback from the users you want rather than the users you have. The users we want aren't going to say they are upset in a github ticket. They just move on.

It's suprising to me that given kitconcept have produced this amazing software, put so much money into it, pushed hard to get it as the default plone 6 experience and then when it's 95% of the way to being perfect, let a few small problems get in the way of a great first user plone 6 experience.
Obviously this wasn't the intention to have an editing experience that requires explanation and training several years ago but that is what plone 6 will be released with IMO.

Other than adding new blocks being confusing if not taught how, the mobile experience is unusable, #3856, cut, copy paste is undiscoverable and unusable on mobile - #1867, inability to close the settings preventing editing on mobile, #3910.

@sneridagh While is great to be able to put one hat on and ignore others, unfortunately there is a UX/product owner hat missing to balance the technical risk with the end user risk. Plone very much misses this role and I'm beginning to think it should be a paid position like release manager. Someone everyone respects like @albertcasado should incentivised to be able to do the thankless job of usability testing and providing quarterly reports on what the biggest UX issues are with Plone.

I suspect now that one reason UX bugs don't get fixed is it's just a horrible experience. Everyone chiming in with an opinion and often work getting rejected because there is no consensus and no hard data and strong "meritocratic" voices incentivised to push for no changes to the UI. I'd certainly be more willing to put more developer resources into fixing these issues if I knew a UX person blessed it first and would fight for the fix going forward. Maybe this is the reason why #682, a 4yo bug that everyone who first tried volto knew about, got left unfixed for 4 years?

[davisagli]

@djay Would you be willing to post that as a new thread on community.plone.org instead of here? I think you brought up some good topics for discussion, but it goes beyond the focus of my PR.

[djay]

@davisagli done in https://community.plone.org/t/should-plone-have-a-ux-manager-role/15891 but I zero expectation anything good will come of it. open source and UX just don't mix.