List widget UX improvements and considerations

[t1merickson]

Problem

The list widget in the editor view has some confusing UX, and while much of this maps to the larger problem of elegantly visualizing nesting, this issue aims to address some problems more immediately than a larger redesign of nesting in the editor.

Action Items:

• The chevron and "n items" label at left of the 'function bar' should act as an expand/collapse all action for all child list items. This was addressed in Add collapse all/expand all to Listcontrol #912 but one slight tweak is needed: the chevron should point to the right, not upwards, when collapsed.

• The 'function bar' should sticky when scrolling in the same way the 'function bar' of the rich text/markdown widget/textbox does.

Questions:

• Should the items in a list be all collapsed by default? Possibly, could this be a preference to site configurators?

• Should the 'add new item' button generate the new list item at the top of the list or the bottom?

• Should the interface automatically scroll to the position of the newly created list item?

[alteducation]

Thanks for creating a discussion around this topic. I would like to share my inputs based on my use case of netlify cms

1. When working with Large Lists, the page load times and site responsiveness can be improved by having lists collapsed by default. I'm sure some people would like the list to be open by default, I think having a site configuration to toggle this would be the best way to go.

2. I add a lot of list entries in one go and having the page scroll up and down for every single entry is a PITA. I think an elegant solution would be to have the new entry list box show up on top and once the details are filled in and the user saves, the list item then goes to the bottom.

[tech4him1]

@alteducation (number 1.) List items will be collaped by default in the next release, the fix was merged in #912.

[t1merickson]

I add a lot of list entries in one go and having the page scroll up and down for every single entry is a PITA. I think an elegant solution would be to have the new entry list box show up on top and once the details are filled in and the user saves, the list item then goes to the bottom.

@alteducation A number of problems abound with that suggested experience. The first is that the new entry can be generated while looking at any position in the list, as the 'function bar' which houses the 'new' button, is supposed to sticky with browser scroll. Thus, you could be looking at the middle, top, or bottom, of the list when you generate the new entry. The second is that populating the new item in one position teaches the user where it belongs, by visualizing it there, and moving it after the creation action would immediately convince the user that the CMS is broken and their post deleted/disappeared. This is a strong anti-pattern in UX design.

A good solution to this problem could be to create a modal that hovers over the screen for the creation action, potentially even with the option in the modal to define wether the item should populate to the top, or bottom, of the list. Upon completion, the interface would scroll to show the position of the newly created item. Keep in mind the 'new' button will always be visible after this scroll, as it will stick with the browser scroll position.

[t1merickson]

Note to self: explore idea of numbered list items and better collapsed state with more info. Also mockup modal creation flow idea

[alteducation]

As you suggested a properly done modal would be a good fit to this solution. It would show up irrespective of the view position.
Another suggestion is an option to display the list in ascending or descending manner and populate the new entries based on that.

[t1merickson]

Another suggestion is an option to display the list in ascending or descending manner and populate the new entries based on that.

I think we'd still have issues as the 'new' button is floating in the sticky 'function bar', which could be scrolled near the top or bottom of the list, and thus would still need to force-scroll the user to the position where the new entry was made.

[erquhart]

I think @neutyp's original suggestion from #928 is best - the combination of making the list toolbar sticky and scrolling to the bottom when a new item is added should be a natural experience for the user. We should avoid modals in general.

[tech4him1]

• The chevron and "n items" label at left of the 'function bar' should act as an expand/collapse all action for all child list items. This was addressed in Add collapse all/expand all to Listcontrol #912 but one slight tweak is needed: the chevron should point to the right, not upwards, when collapsed.

Fixed in #1059.

[ghost]

Since the button to add new list items is placed on top the the list widget and the new entry box gets displayed at the bottom of the list widgets, on large lists user has to manually scroll all the way down to input the data.

@neutyp had proposed auto-scrolling the viewport to the bottom of the widget, please implement this.

Also to add the next item the user has to scroll all the way up again as the new item button is placed above.
neutyp had proposed to keep the new item add button fixed on the header, or like a floating button. I don't know how this will work with files containing multiple lists.

possible solutions

1. Could you add the 'add new list item' button to the bottom part of the list as well as the top to avoid rescrolling'
2. Alternative solution is to add a 'scroll to the top of the list' button at the bottom of the list widget

NB - Displaying list items like how blog posts are displayed, like this - https://nupic.co/image/6TnWX would free up a lot of vertical space

[erquhart]

The two original issues here are chevrons should point right, which was addressed, and improving how items are added, which will now be handled under #1244.