Data table entry: creation vs editing – how to design workflows for least friction and effort

I am designing a new feature and workflow in our business application, which allows administrators to create export configurations, which can later be selected by users, to quickly export projects with a certain configuration. The goal is to let users more quickly and conveniently export their data, so they can use it in other applications.

These configurations contain vital information such as:

  • Which parts of the project to export
  • Which file format to export
  • Whether to download the file or store it on a (pre-configured) server
  • Should the file be compressed or pretty-printed
  • etc.

Currently, when exporting data, the dialog that’s presented to the user, might look something like this:

enter image description here

Administrators are able to see a table of all available configurations, which looks somewhat like this:

enter image description here

Admins can Add Configurations (as indicated by the top right corner button), which opens the dialog (first image, but replaced export button with save) and lets them save this configuration, which gets added to the table. Subsequent editing could take place in the data table itself, by means of expanding the respective row and changing values in place, without the need of a dialog.

My question is this:
In order to cause the least amount of distraction and cognitive load, I opted for the in-table-editing, while still leaving the creation process in a dialog.
My reasoning for this is that the process of creation is mentally relatively separated from the context you start out and warrants the use of a dialog. Yet, editing (possibly multiple) configurations later on, while maybe even comparing them, would be severely interrupted by having to open a dialog for every configuration – which would also severely impede the ability to scan and compare while editing.

One of my colleagues argues that, to the contrary, the creation and the editing process should take place in the same “established” environment – namely the UI of the dialog – in order to remain consistent and not have two different interfaces displaying the same information.

Which procedure is more recommended in order to keep the administrator’s effort (both cognitive and manual) the lowest possible and aim for the least friction in the workflow?


How to design intentional friction in app?

I am designing an app for iOS where I need to prevent user to unintentionally trigger an alarm (the action of calling for emergency should be easily accessible but at the same time should prevent any accidental initiation).

I don’t want to use confirm dialog since it requires user to read and looking for a button in different position. (seems like too much friction on the other side)

What occurred to me initially as an good idea was to use ‘slide to’ action button, similar to what was/is used to unlock iPhone screen, but then I run to this topic: basically saying that Apple discourage usage of these kinds of components refuse to publish such an app in the store.

Do you have any experience with this kind of user scenarios? Or do you have experience with apple refusing to publish your app for such reasons?