Support reordering of grid rows with drag and drop - Githubissues

orbeon / orbeon-forms

Orbeon Forms is an open source web forms solution. It includes an XForms engine, the Form Builder web-based form editor, and the Form Runner runtime.

http://www.orbeon.com/

GNU Lesser General Public License v2.1

513 stars 220 forks source link

Support reordering of grid rows with drag and drop #2461

Open ebruchez opened 8 years ago

ebruchez commented 8 years ago

This is an obvious one as that would be much more user-friendly as the current system with menus.

This is a given for the full appearance. With the minimal appearance, which doesn't have menus right now, we could also make it an option.

+1 from customer

ebruchez commented 8 years ago

+1 from customer for easier reordering, possibly with a menu in addition.

ebruchez commented 7 years ago

For Form Builder, we just introduced drag and drop in the new workflow UI (see 3acb9a1082b3c9883828ac69699061d941e7a60f and 61aecd667dd46d703d6d3dd1804443552116dce6). This gives us confidence that it would be easy to add drag and drop to repeated grids.

ebruchez commented 7 years ago

full appearance
- Decide how to do the drag as we need a draggable handle somewhere, probably.
- Do we keep the menu at all? We still need a way to insert and remove.
- Should this be a new appearance of fr:grid?
- Maybe appearance="full dnd"
minimal appearance
- Similar questions, except we don't have the menu. Maybe appearance="minimal dnd"
consider fr:section / fr:repeater too
consider whether this is the time to introduce Scala.js to Form Runner, as use it for fb:dnd-repeat, but not for fr:tabbable

Syncopatico commented 7 years ago

For long lists, we'd also like to have an 'insert before/after ' option for moving items around grids, and an option to display and access a grid item number (bit hard to specify N without it). It would also be useful to have a duplicate function, where a grid item would not just be inserted after, but include the values entered in the current grid item (a bit like 'fill down' in a spreasheet). This can be useful where list items might contain some repeated values.

ebruchez commented 7 years ago

@Syncopatico Here are the separate issues I entered:

Repeated grid: option to show a row number #3189
Repeated grid: option to duplicate row with content #3190
Repeated grid: move grid row to before/after another grid row specified by grid row number #3191

ebruchez commented 7 years ago

We had a quick look at the difficulty of doing the drag and drop (#2461) and it doesn't seem that hard, based on some support we already have in Orbeon Forms 2017.1 for drag and drop (see DndRepeat).

ebruchez commented 7 years ago

Also consider keyboard shortcuts for moving.

Syncopatico commented 7 years ago

@ebruchez - I think a 'move to before/after row N' might work better than keyboard shortcuts, which would only move things one row at a time. With the repeating grid we have seen some odd behaviours when a large sequence of move instructions are given to it in rapid succession (such as when someone wants to move something several rows), and keyboard shortcuts may exacerbate that situation.

ebruchez commented 7 years ago

@Syncopatico Moving a row up/down with keyboard shortcuts would be in addition to drag and drop, which is what this issue covers. Moving to a given position by entering a number is covered by #3191. I think all those options can make sense depending on use case and the user's proficiency.

avernet commented 7 years ago

For consistency, I am changing some of the icons around controls, grids, and sections to use the Bootstrap icons, for consistency, and I notice that for controls, sections, and grids settings we use a cog icon, while for the form settings we use a tool icon. I think we should use the cog or the tool icon everywhere, but am undecided as to which one is best. One argument for cogs is that this is what Apple uses for their Settings (iOS) and Preferences (macOS). So I'll go with that for now.

avernet commented 7 years ago

Next, I want to:

[x] Get the fb-section-editor to stay visible when the mouse is over it, even if it moves to another section.

This is so we can have more icons on the left of the section (at least 1 for the D&D), and will also solve the situation happening currently where one can't reach all the icons if the section is collapsed (less important) or contains a subsection (more important).

avernet commented 7 years ago

Another way, most likely simpler to implement, and arguable even more usable, would be to leave the fb-section-editor visible, for the last section the mouse was inside of, as long as the mouse is inside the main form editing area.