12.0p ListGrid on mobile improvement suggestions

[Blama]

Hi Isomorphic,

I have improvement suggestions for mobile, all in the same area:

ListGrids on mobile with canMultiGroup, canMultiSort or useAdvancedFieldPicker (with a default threshold of 0, or not watching the threshold) should use a mobile-adjusted layout for their respective dialogs.

Something like in the new 12.0p Touch Drag sample with a ListGrid of available columns and a ListGrid of already used columns. One at the top, one at the bottom.
Perhaps also left/right if on Tablet (only if in landscape?) compared to Handset.

Also a mobile-friendly easy filter builder in its own window would be great (no support for nesting, just plain AND as in the normal filterRow).

The ListGrid itself is working good in mobile if you strip it down (effectively no context menu on the header), but interacting with it other than scroll and click is not good.

What do you think about this?

Best regards
Blama

[Isomorphic]

Hi Isomorphic,

I have improvement suggestions for mobile, all in the same area:

ListGrids on mobile with canMultiGroup, canMultiSort or useAdvancedFieldPicker (with a default threshold of 0, or not watching the threshold) should use a mobile-adjusted layout for their respective dialogs.

Something like in the new 12.0p Touch Drag sample with a ListGrid of available columns and a ListGrid of already used columns. One at the top, one at the bottom.
Perhaps also left/right if on Tablet (only if in landscape?) compared to Handset.

We agree that adding drag handles makes sense for the Multi-Group, Multi-Sort, and AdvancedFieldPicker dialogs. However, beyond that, we don't see much of an issue with the Multi-Group or Multi-Sort dialogs on mobile, other than perhaps that there should be a way to gracefully complete editing of a row, such as by touching an open area of the grid. (On desktop, hitting "enter" completes editing.) For those two dialogs, other than drag handles, what sort of awkwardness do you see with the UI that could be corrected?

For the AdvancedFieldPicker, we do agree that the current situation where the two grids are placed side by side may make the UI cumbersome, so that you have to drag scroll inside each grid to see much of anything. However, if you only cared about the column titles, the side-by-side layout might be sufficient, and does show quite a few rows. If we changed the orientation to top and bottom, it's true you'd get more horizontal space, but then the number of rows would be much less, given the requirement to show the filter editor for each grid and have space between them for buttons, etc. So, if we were going to allow top and bottom placement, we'd need to make the orientation configurable, with the default dependent on handset orientation, but we do see how it might make things more flexible.

Another option is to actually break the two grids - "available" and "visible" fields - into separate screens much as we do with the SplitPane. Obviously, you wouldn't be able to drag between the grids with them on different screens so you'd need to use the transfer buttons, but much more screen area would be available for each.

Does this summary agree with your experience? We are leaning towards just providing a configurable orientation as a solution here, since it still allows dragging.

Also a mobile-friendly easy filter builder in its own window would be great (no support for nesting, just plain AND as in the normal filterRow).

We looked at the Advanced Filter Feature Explorer sample on mobile, and don't see your point about putting it in a separate window. With a single swipe, you can position the FilterBuilder so that the criteria you're adding start along the left edge of the screen no matter the orientation, giving you the same space as if it was in its own window. Were you imagining some layout different than having a horizontal record for each criteria in the filter?

The ListGrid itself is working good in mobile if you strip it down (effectively no context menu on the header), but interacting with it other than scroll and click is not good.

We're not sure we get your point here. You can long touch on any header button to launch the context menu for that button, which appears as a "pop out" picker just like every other picker does on mobile. There's no need to (short) touch on a header to get the headerMenuButton to appear - which would also trigger an unwanted sort. If your suggestion is to hide the headerMenuButton by default for mobile, that seems reasonable, especially since the headerMenuButton "sticks" and blocks visibility (if anything's under it).