Document lists: Research UX and create a state graph

[magda-chrzescian]

It should define a way to execute the following actions:

1. Extending text without creating an indentation,
2. Inserting an image to a list item, while the image is in a new line. Similar to case 1.
3. Inserting a new item,
4. Definition list, where the first line is bolded,
5. Escaping a list,
6. Merging items
   • Is it the same case as merging two lists? Not necessary, it will depend on our implementation.
7. Removing items
8. Splitting lists to create a new list,
9. Splitting a list to insert a new paragraph,
10. Indent and outdent,
11. Changing a list item into a heading (while maintaining the bullet)
    • Use case: Implement advanced lists (document lists) #2973 (comment)
    • Problem: Bullet will not be styled as a heading (bigger, bolder)
12. Changing heading back to the list item
13. Subsequent lists
14. Merging subsequent lists by Backspace.

Additional concerns:

• Handling above cases will depend on the selection position.
• Button states when inside a multi-block item?
• How to make the first block of a list item a list iteself?
  • This creates this weird situation with two bullets in one line.
  • We do not have to support this from the UI side.
  • We need to be able to load such a content, though.
• Side task: Show blocks feature
• Could double enter in the block mode leave the item?
  • In Google Docs we stay in the block mode.
  • In our case, we could either: leave on a double enter, make even the first enter leave (and force people to use enter+backspace to create 2+ blocks items).
  • We do not have to make a decision now – it's relatively simple to change.
• What about subsequent lists?
  • We need to handle loading such content.
  • But we don't need to make it possible to create such a content in the editor.
  • Problem: Paste. You might start with a clean content and create a mess by pasting content that had multiple subsequent lists.
  • Possible direction: Merge on paste, don't merge on setData(). Reasoning: Make sure we're not creating a shitty content in cases like GH Writer and other simple, semantic editors.
• Indicating the block mode.
  • Just a distraction. Or impossible to understand for users.
  • Also, is it even necessary?

[magda-chrzescian]

We decided to go with the UX described in the following document: https://miro.com/app/board/o9J_lVbklBg=/.

The decision left to be made

The behavior of the list item while selecting the heading type in the list item with no nested blocks inside. There are two possibilities:

• To convert the list item to a header and escape the list mode
  • We don't want to allow the HTML like <ul><li><h1>text</h1></li></ul>.
  • So how to produce <ul><li><h1>text</h1><p>text</p></li></ul>, which we decided to allow anyway?
    • Converting the first item to the header should be possible only if some blocks are already nested in the li.
  • The above solution may be hardly discoverable.
  • It is inconsistent and unexpected in the document editing.
• To nest the h1 element inside the li
  • This is a consistent behavior - whether we have nested blocks inside the li or not, the heading button does the same thing.
  • It may produce an ugly, unstructured HTML output.
  • This can be unexpected and unnecessary in the structured editing case - one can expect to split the list with the header. But we don't really have any data about that.

Regardless of the above, we have to allow the developer to limit the lists' functionality to the basic version with no block content allowed in the list elements.