BlockList Range UX Follow up on (issue #8894)

[TRexStark]

Which Umbraco version are you using? (Please write the exact version, example: 10.1.0)

10.4.1

Bug summary

I understand that the decision was made based on what happens on other editors as @nielslyngsoe stated on issue #8894.

I see that @nathanwoulfe changed the PR to display the text and not hide the button.

Sorry guys, but I don't think that it makes sense to limit the amount of Block items and still have the button to add another.

If we compare with textarea with limited characters, that is only a textarea and the adjustment to be made is straight easy.

Now BlockList is a different beast, imagine if I have a complex BlockList with so many properties, then with nested blocks and complex settings, then I'm forcing the average Joe editor to go in and spend half an hour adding their content, only to notify them at the end that they have 1 too many.

It becomes a frustrating experience for the editor. This is a simple UX fundamental to make the editor's experience more friendly and easy.

Steps to reproduce

Create a complex BlockList with Nested Blocklist and settings.
Limit the amount to 1.
Add your content in the first one, then try to add the second one even if you know already that you can only add one.
Act as an editor who doesn't know what's happening behind the scenes.

Expected result / actual result

If you set a range limit to blocklist and the amount of block items added by the editors have been reached, the "Add" button should either be grayed-out or hidden (preferably).

Similar to a Multi Node Tree Picker which is the perfect example, when you limit the amount of nodes to be picked, then the "Add" button doesn't show when the limit is reached.

This solution also eliminate having an additional button that does nothing.

[github-actions[bot]]

Hi there @TRexStark!

Firstly, a big thank you for raising this issue. Every piece of feedback we receive helps us to make Umbraco better.

We really appreciate your patience while we wait for our team to have a look at this but we wanted to let you know that we see this and share with you the plan for what comes next.

• We'll assess whether this issue relates to something that has already been fixed in a later version of the release that it has been raised for.
• If it's a bug, is it related to a release that we are actively supporting or is it related to a release that's in the end-of-life or security-only phase?
• We'll replicate the issue to ensure that the problem is as described.
• We'll decide whether the behavior is an issue or if the behavior is intended.

We wish we could work with everyone directly and assess your issue immediately but we're in the fortunate position of having lots of contributions to work with and only a few humans who are able to do it. We are making progress though and in the meantime, we will keep you in the loop and let you know when we have any questions.

Thanks, from your friendly Umbraco GitHub bot 🤖 🙂

[Zeegaan]

Hey! 👋 As Niels states in #8894 (comment) this is intended behavior and not a bug. Thus I will move this to this discussion, as it's a feature request 😁

[nathanwoulfe]

Heya @TRexStark

I'd still lean in the direction discussed in #8894 - the user should be able to add (and save) more than the limit, but only publish when the number of blocks is within the configured range. We want to keep editing flexible as possible. MNTP is a different context as the property editor lacks the complexity of block list/grid, so there's little cognitive load in removing a link to add a new one (compared to blocks, where the content setup can be quite involved).

I wonder if the solution could be an additional UI notification when adding limit+n blocks - a dialog warning that the page can not be published until n blocks are removed? This way the user is notified when they attempt to add the block, and can make an informed decision before they continue (or not). I know we generally don't want to add configuration for everything, but this approach could then be extended to allow setting a preferred behaviour - either 'warn' or 'hide' to control how the button behaves when the limit is reached. That would leave implementors free to decide which approach works best for their users.

[Zeegaan]

@nathanwoulfe You do get an immediate warning when you add the block. But I guess it's not that clear that you can't publish it if you're not familiar with Umbraco.

[nathanwoulfe]

Perhaps we need to revisit that text and make it a bit more helpful. Makes for an easy change if it's just a validation message update

[TRexStark]

@nathanwoulfe and @Zeegaan that is an ok case when it's inline, but if you're using the infinite editor, you kind of see it if you have an enough big screen, which will take me to Nested BlockList, with a secondary infinite editor going over the first one, there is a high probability that you will miss the message.

[nathanwoulfe]

Good point. Brings me back around then to a dialog with a warning that the page can be saved but not published while it has more than the max permitted blocks.

[nielslyngsoe]

Good one @nathanwoulfe, the user feedback can definitely be improved.
I'm not sure technically if we can know upfront if there was a validation error. But it would be an okay solution to show a dialog in this case where the document was saved but did not publish. Like a summery of what happened, so clarify to the user that it was saved but not published.

[TRexStark]

To be honest, I'm not sure why there is a resistance on hiding the "Add" button when you reach the limit. I thought that would be the easier solution, because you will do a comparison "if amount of BlockList items = RangeLimit" then hide. But whatever that reason is, the dialog suggested by @nathanwoulfe would practically do the same check and show the dialog at the start.

For me personally, I don't see a reason for allowing editors to add content that is not going to be published anyway.

[nielslyngsoe]

Hi @TRexStark, @Zeegaan & @nathanwoulfe

Good discussion going on here — I'm not so often on GitHub these days so sorry for pitching in this late.

I think you are all right. We should keep the ability but it's not clear enough for the user what the validation error is about. The descriptive text is drowning when working with visually large Property Editors.

Here is a reference screenshot from the experience when pressing Save & Publish:

I would say this issue can be solved purely visually.

As I see it, the user is potentially confused by there being two validation messages. The general "This property is invalid" and the local-specific validation description which is seen in @Zeegaan recording above.
The first one is not very descriptive and does not guide the user, so it would be ideal if the Property Editor was technically able to provide a more descriptive error message to be shown instead(or within) the general validation text speech bubble.

But for that to work well, we need visually to have the validation-text-speech-bubble following along the screen, so we don't end up in a situation where the users is further down the viewport and thereby not able to read this one. In other words:

The 'local' validation description should be visible in any location within the Property Editors — As long as there is some of the Property Editor within the viewport, then we should be in sight.

And please notice when clicking Save & Publish the view should switch and scroll to the first Property containing an error — If that's not the case in all situations then that's clearly an issue.

I think this can be turned into an up-for-grabs issue

Thanks for the input and concern — I always love these issues regarding Content Manager's experience.