Topic on VisualEditor/Feedback

Table tests and use case studies + bullet/numbered indented list bug

2
184.151.114.144 (talkcontribs)

Hello, here are some tests I have done with tables. I have quite a few different cases to be covered here, so I'll separate them by bold text.

1. Typing a backspace on the first character of text below a table makes that table "eat" the following line.

In my test, seen here (first table in the code's edit), I tried editing the content of the headings right below the table in section Heading 2aa. The result was such: one too many backspaces made the headings jump into the last cell (code-wise) of the table, stripping their heading format and appending their line's text to the cell.

A second test, seen here, has me styling text and trying to append it to the last cell of the table. The text retains its styles.

In my third and final test on this subject, seen here, I created a heading and applied multiple styles before moving the text into the table. The styles were retained, but the heading was stripped due to the text being appended to the end of the last cell's last line.

In conclusion, this shouldn't actually happen. Jumping from text into a table cell with backspaces can cause some rather unfortunate problems, especially if you accidentally move a large paragraph into a compact table with narrow columns. The stripping of headings is also a loss of data, since we lose all reference to the heading's previous level.


2. Moving between cells in edit mode is impossible.

While not necessarily a universal concept, it is a usability enhancement that would make things far less annoying: while editing a cell's content, I have not found a way to move to an adjacent cell without having to use the mouse to select a different cell.

Many systems accept the use of the Tab and Shift + Tab buttons to move between cells in a row (wrapping to the next/previous row if at the extremity) without using a mouse. Others additionally or alternatively accept the use of the arrow keys when at the cell's editing border in order to jump to the next cell (Up needs to be on the first line, Down on the last line, Left on the first character of the first/current line, Right on the last character of the last/current line)


3. Entering a cell's editing mode should put the text cursor where the user has clicked

This is another usability quirk: it takes a double-click (for edit mode) and a separate single click in order to reach the user's required editing target. This is can be an annoyance for people who edit tall cells that exceed their screen's size, since the cursor's position isn't immediately apparent.


4. Alternating between bullet and numbered lists with indentation is buggy

Do the following steps:

  1. Add a bulleted list with text.
  2. Add a second bullet with text. Increase its indentation once.
  3. Change the second, indented bullet to a numbered list.
  4. Change the second, indented number back to a bullet.

VisualEditor removes the number, removes the bullet and all indentation. If done within a list of mixed bullets and numbers, it effectively breaks the list by dragging the following list item to the first level.

Proper functionality should be that the entire indentation level changes to bullets. All other indentation levels should not be affected. If the list is of the following kind:

  • Indent 1-1
    1. Indent 2-1
      • Indent 3-1
    2. Indent 2-2
  • Indent 1-2
    1. Indent 2-3
      • Indent 3-2

Changing the numbered list at 2-1 should affect 2-1 through 2-2, but not 2-3.

My test was done with the following list, which was subsequently modified here.

184.151.114.144 (talkcontribs)

For reference, I used Firefox 33.0.2 for those tests.

As for Chrome 38.0.2125.111, I got similar results.

This is the original list and this is the broken list while using Chrome.

Thanks again!

Reply to "Table tests and use case studies + bullet/numbered indented list bug"