Smarter list widget additions

[erquhart]

- Do you want to request a feature or report a bug?

enhancement

- What is the current behavior?

Adding items to the list widget is painful - you have to:

• scroll to the add button up top
• click it
• scroll to the bottom of the list
• edit the newly added item
• reposition the item to desired location

- What is the expected behavior?

• scroll to desired new item location
• click an in-location add item button
• edit the new item
• rejoice

I imagine a full width button, maybe a dashed outline with a plus sign that appears between any two list items on hover.

[tech4him1]

Related to #963

[erquhart]

Agreed, this can be considered a sub-ticket under #963.

[mittalyashu]

Very simple design, hope you like it 😋

Here's the source file.

[erquhart]

Interesting! What's the red dot for?

[mittalyashu]

There is still a room for improvement, it's just that I wasn't sure how people will write their config.yml file. 😅

What's the red dot for?

https://youtu.be/l28MCjo-Jxs?t=581

[austincondiff]

I completely agree that this is very painful. I don't know why this isn't here already, especially considering the amount of vertical space each list item takes.
This issue hasn't been touched for about a year now. Any movement here?

[erquhart]

This is open source, not a paid service, so the community does a fair amount of the heavy lifting. If you're up to contribute I'm happy to answer questions and help any way I can.

[melbourne2991]

I just put this together - code is pretty much ready to go (just need to add the actual insert, tests etc) - thoughts?

Edit: Oh and It's a lot snappier than the gif's framerate would make out

I actually went with this approach first:

"I imagine a full width button, maybe a dashed outline with a plus sign that appears between any two list items on hover."

The issue I found with this is because you're inserting the button between list items it causes them to jump around, which can be annoying if you are not trying to insert something and are instead trying to click the expand button or drag handle for example.

[erquhart]

Thanks for digging into this @melbourne2991! I still think the approach I mentioned would be ideal - the jumping is totally avoidable with CSS. If you can update to what you had I can help with that part.

[melbourne2991]

@erquhart I pulled some of the code out into this sandbox to help illustrate the various approaches:
https://codesandbox.io/s/solitary-rgb-brg22

There are two visual styles and two "strategies" for displaying the insert button:

Samples A and B always show the button based on the mouse position within the list.
C and D only display the button when hovering between the items.

A is closest to what you initially described I believe? C and D feel kind of jarring to me, but maybe that's just a matter preference. I like B as I find it to be least intrusive but I can see how A might be more intuitive/obvious as it clearly highlights where the item will be inserted.

Should I push on with A?

[ZoltanVeres]

This is excellent work, truly awesome that we test out versions!
My bet is on A, because it visualizes where the item will go, B could also work too.
C and D is not going to work on mobile, because it only uses the hover state so can’t add items from mobile.
I know the CMS is not fully optimized for mobile, but we should avoid solutions which exclude these usages.

[tomrutgers]

IMHO B is easiest to use. Maybe the button should be slightly more subtle if it's always going to be there. I'm also curious about the flow with the types list widget! BTW Homerun.co does something similar, I think it works really well: https://demo.homerun.co/?demo=job-editor

[austincondiff]

I really think there is too much movement in all of these examples. There may be a larger problem to be solved here.

Adding items in between two others seems to be a use-case easily solvable by dragging a newly created item to the desired place. It seems overly redundant to have the button appear in between.

If we wanted this functionality, each item might have a menu where we could add two items "Insert one above" and "Insert one below". While we are at it we might add a "Duplicate" option as well (in my experience this would be very beneficial). This way things are out of your way unless you need it and it is much more scalable because we now have room for additional actions if we needed to add them in the future.

[melbourne2991]

@austincondiff I like this. It has the additional benefit of being able to work on mobile flawlessly. Do we need the move up / move down buttons though? I think rearranging is much easier with drag and drop, which is the current behavior.

[erquhart]

Inserting between items is important. You wouldn't think so until you actually need to position items regularly in a long list (some have hundreds). WordPress Gutenberg uses buttons that appear between items on hover and it works great, though they're definitely not the first.

@melbourne2991 thanks for putting this together, I'm on mobile right now but I'll check it out next time I'm at my machine.

_{Sent with GitHawk}

[austincondiff]

@erquhart Yeah, I figured adding items in between was important, especially when each list item has many fields.I was more-so concerned about the movement. Motion can be the biggest eye-catcher in a design. That being said, I think this makes users focus more on the UI as opposed to the their content.

@melbourne2991 In this concept we would still be able to drag and drop. We don't necessarily need the “Move Up” and “Move Down” menu items, however I would imagine it improves usability on mobile where it may be difficult for some to drag and drop. Some mobile browser experiences make this pretty difficult depending on the device.

This pattern of adding items in place via context menu also exists in google sheets...

[erquhart]

Example of an indicator that appears in the space between blocks without any impact to surrounding elements: https://wordpress.org/gutenberg/

That page is the live Gutenberg editor, try inserting a block between blocks. We could probably use something thin and wide since the space between list items has no other purpose.

The Sheets approach in Austin's last comment also would work, just need to consider implications of adding context menus to every list item.

[austincondiff]

@erquhart It is interesting because it looks like Gutenberg does both...

I will say that this is a page builder use-case and not a repetitive list as in our situation, but there might be room to draw inspiration here.

I do like their approach because their button is a small and simple icon that does not affect layout.

[austincondiff]

Under the design outlined in #2557, this could work well...

Hover state...

If the list has types...

Via context menu...

[erquhart]

Come to think of it, between the two approaches, context menu is the only one that would work on a touch device, so maybe it is the best initial approach.

[austincondiff]

@erquhart I've made a sandbox to demonstrate both of these concepts

https://codesandbox.io/embed/netlify-cms-editor-design-j1cg3

As mentioned #2557 (comment) it's not perfect but it should give you an idea as to how this might work.

[erquhart]

That sandbox is pretty fly, nice work! For this immediate feature being something we can implement without expanding scope, I think adding just a blue line that shows on hover in the existing space between items is probably our best bet, whereas your proof of concept would likely be a part of a larger rework - at a minimum its a rework of the list widget. Would love to see some of that added to the current list widget 👍👍

[erquhart]

Using Google Slides and noticed there's no direct way to insert a new slide, but if a slide is selected, the new slide will be inserted after the selected slide. This works because the slides panel scrolls independently of the rest of the UI, and the add slide button is in a fixed toolbar.

The more I consider this approach the more it seems extremely ideal, not just for smarter list item insertions, but for improving the UX for nested widgets like object and list. The markdown widget toolbar is sticky, so for long markdown widgets, the toolbar sticks to the top of the screen until you pass the end of the widget. What if we did this for the object and list widgets? The toolbar is always visible, which also means you can collapse the whole thing at any point. For multiple levels of nested widgets, the sticky toolbars can stack, and hierarchy will be obvious. We could even make the toolbar thinner when it's sticking.

Thoughts?