as a first step, we are thinking about leveraging the existing contextual menu (used to change the mode or delete a list item) to also display 2 new options: move up, and move down.

in the scenario where editors would open the contextual menu for the first (or the last) list item, the non-valid menu option would be set to inactive.

Please consider supporting “insert item”. It looks like adding a new item near the start of a list would not be a great experience otherwise.

@Bugreporter specifically refers to the case: “if an element is missed”. Personally, I haven’t felt the need to change the order of a list, but when I used to use line-editors, years ago, “insert line” was a much more frequent operation than “move line”. I think that’s still true of rows in spreadsheets, whereas cut and paste is more common elsewhere. If we had “insert item” as a first step, the ability to select an existing item to insert would be a natural second step (equivalent to cut and paste).

Not too far off-topic, if we had a useable design for moving objects around in a composition (a much higher priority for me), a consistent approach would seem desirable.

thank you @GrounderUK

In T359664#9705990, @GrounderUK wrote:

Please consider supporting “insert item”. It looks like adding a new item near the start of a list would not be a great experience otherwise.

@Bugreporter specifically refers to the case: “if an element is missed”. Personally, I haven’t felt the need to change the order of a list, but when I used to use line-editors, years ago, “insert line” was a much more frequent operation than “move line”. I think that’s still true of rows in spreadsheets, whereas cut and paste is more common elsewhere. If we had “insert item” as a first step, the ability to select an existing item to insert would be a natural second step (equivalent to cut and paste).

that's a great feedback. a possible workaround with the current proposal might be to add a new list item (currently it's added at the bottom of the list) and then move it up to the desired position. lemme file a new task about "insert here/below/above".

Not too far off-topic, if we had a useable design for moving objects around in a composition (a much higher priority for me), a consistent approach would seem desirable.

we also explored a drag-and-drop interaction, but it's a pattern that is currently not supported by Codex, and we wanted to reduce the scope of this very first iteration on sorting lists. that said, i'll file a task about moving objects in a composition!

Change #1019058 had a related patch set uploaded (by Genoveva Galarza; author: Genoveva Galarza):

[mediawiki/extensions/WikiLambda@master] Add Move up and Move down options to typed list item menu

https://gerrit.wikimedia.org/r/1019058

Thank you 🙏

In T359664#9706260, @AAlhazwani-WMF wrote:

…we also explored a drag-and-drop interaction…

That looks pretty classy!
🤔…but a purely drag-and-drop solution has accessibility implications, so “insert” should be the priority.

In T359664#9709254, @GrounderUK wrote:

Thank you 🙏

In T359664#9706260, @AAlhazwani-WMF wrote:

…we also explored a drag-and-drop interaction…

That looks pretty classy!
🤔…but a purely drag-and-drop solution has accessibility implications, so “insert” should be the priority.

totally agree! that was one of the reasons that made us pause a little longer on drag-and-drop, and wait for a more solid and accessible solution from Codex. as far as i can tell there are ways to make this interaction accessible via keyboard-only[1][2], but we'd like to test this extensively, and leverage the design system team extensive know-how on a11y best practices.

[1] https://dev.opera.com/articles/accessible-drag-and-drop/
[2] https://pressbooks.library.torontomu.ca/wafd/chapter/sortable-lists/

In T359664#9709817, @AAlhazwani-WMF wrote:

In T359664#9709254, @GrounderUK wrote:

Thank you 🙏

In T359664#9706260, @AAlhazwani-WMF wrote:

…we also explored a drag-and-drop interaction…

That looks pretty classy!
🤔…but a purely drag-and-drop solution has accessibility implications, so “insert” should be the priority.

totally agree! that was one of the reasons that made us pause a little longer on drag-and-drop, and wait for a more solid and accessible solution from Codex. as far as i can tell there are ways to make this interaction accessible via keyboard-only[1][2], but we'd like to test this extensively, and leverage the design system team extensive know-how on a11y best practices.

[1] https://dev.opera.com/articles/accessible-drag-and-drop/
[2] https://pressbooks.library.torontomu.ca/wafd/chapter/sortable-lists/

It’s a good start, but we should add “stylus-only” to “keyboard-only”, for users of touchscreen devices. I don’t use a stylus myself, but iOS’s zoom-on-entry “feature” makes single-digit operation challenging (fortunately, I can use all mine).

Change #1019058 merged by jenkins-bot:

[mediawiki/extensions/WikiLambda@master] Add "Move before" and "Move after" options to typed list item menu

https://gerrit.wikimedia.org/r/1019058