Data tables/grids in task based UIs

Question

I'm designing a business web application. I'm leaning towards a task based UI style, but I'm facing a challenge regarding the creation of complex entities such as orders, composed of order lines.

A CRUD approach would be a data grid: as part of the order creation you manipulate the grid of order lines, adding, editing and removing order lines, and committing the entire order (order details and list of order lines) as a single task.

I believe a Task based approach would be first to create a draft of the order with essential data (i.e.: customer and delivery address), and then manipulate the order lines with atomic tasks, either with inline edition for a single order line or with a modal for each task. My intuition tells me that this could be more tedious for the users, as instead of entering data into any input of the grid, each task would require a little more interaction:

1. edit every order line in batch
2. save the order

vs:

1. For each new order line:
   • create a new order line
   • enter its data
   • commit it (this action would not be required on a CRUD grid)
2. For each order line that requires a correction:
   • start the fix (not required in CRUD)
   • correct the data
   • commit the fix (not required in CRUD)
3. For each order line that is no longer required:
   • remove the order line

My first question is if I am understanding the Task Based UI pattern correctly for this particular case, or if are there any other approaches more friendly for the user? (maybe there is an alternative approach)

My second question is if are there any Task Based examples of scenarios like this that you can recommend me (either real world or materials, as I couldn't find any example dealing with this particular type of interactions).

Answer 1

An increasingly common expectation today is that every action which can be persisted, should be, as atomically as possible. Each task should be saved as soon as focus is lost, so that if the user needs for any reason to reload or change devices, they only lose a few keystrokes at most.

What this means is that dedicated "submit" buttons are largely disappearing. The experience is naturally streamlined by virtue of the fact that the user is not breaking his flow to individually submit his changes. This is true whether the child elements are just properties of the main object (i.e, the title of the order), or objects unto themselves (e.g., a line item with its own properties).

As much as possible, all changes are expected to be inline, but if a child object has sufficient complexity, modals may be useful. Another emerging pattern that eliminates floating modals is expanding views - that is, showing additional features for the item while it's being edited, and collapsing those when editing is complete, to keep the lists tight.

Because this means that items are necessarily saved in "incomplete" states, it's useful to have a "snapshot" feature that can distinguish major revisions, and/or a "publish" feature that lets other users and services know when the final version is ready. These replace the traditional submit button with the benefit of making the intention of a given update much more explicit.