There is no definite answer for this.
From both usability and implementation perspective, the two are rather different; and they fall into record-editing strategies. Records can be presented in a tabular form, but events on a calendar are also considered records.
Essentially, the decision boils down to a few main factors:
- How complicated the record is:
- Amount of fields
- Validation complexity
- How often users need a quick way of editing specific fields?
- Would users benefit from seeing other records on screen, while editing a record?
You have, in principle, 3 leading patterns:
The modal dialog
When the user wish to edit a record a model dialog is shown. There are a few advantages to this pattern:
- It implements dead-end navigation. Meaning users can't navigate anywhere other than back to where they came from by pressing Save or Cancel to exit the dialog. This type of navigation is very intuitive and clear, where users shall be clear about what will happen (unlike with some other solution).
- It allows
- It allows a delete guard - to prevent accidental deletes, many interfaces put the delete button deep in the interaction hierarchy. A dialog allows to 'burry' the delete button within the dialog, ensuring users have to click at least once in order to request the delete of a record.
- The fact we are using a dialog means there's more display space, which helps:
- to present help text
- cluster the data into headings
- present validation errors in a clearer manner
- It is allows one-to-many data manipulation. Say a record can have multiple attachments - the fact we are showing a window allows the editing of these.
- Programmatically this type of pattern is easy to implement - when the user create a new record, it is only created on the client side, and only sent to the server upon Save. With other solutions the implementation is a bit more complex.
Note that a variation of this pattern is a dead-end page. Meaning we do not present an overlay dialog, but navigate aways to a page where you (in principle) can only perform Save or Cancel. This is how Google implements event editing:
One thing to consider about this pattern, is that it can get somewhat cumbersome if we have to navigate to another form. For instance, if one of the record fields is customer and you wish to provide an ability to add customer, which requires to show additional form. In general, a modal from a modal is not a great idea. And the most elegant solution to it is the implementation of the hub-and-spoke pattern in a mobile-interaction fashion.
In-place field editors
The advantage here is that it is quick - users can simply click and edit a field, without navigating away from the view.
There are a few complexities though:
- How exactly we know the user has finished editing the field? Mostly this is achieved via OnBlur event, but what if the user clicks a nav item while the editor is still open?
- How do we signify to the user that the change has been persisted to the server (database). Once done editing, a request is sent to the server and the server will return with success or failure. ExtJS, marks the field with a small red triangle on the left-top corner, and when the server returns success the triangle disappear. A further complication is the case when a field has been edited, but the user has navigated away from the screen before the server returns.
- How do you provide success/fail feedback for data that is no longer on screen (and programmatically you have to account for this, or you'll get an error).
- Displaying validation errors may be a bit less straight forward in this case (specifically as some validation happens on the server - consider session timeout, for instance).
- Programmatically, when the user clicks Create you would normally send a new record request to the server, getting back a new ID, then populating the table with the new record that can be edited.
Compare these to the advantages of the modal dialog, and you'll see that many are not supported by the in-place pattern. For instance, there's no cancel option.
Another thing to consider (particularly with this pattern, but also with the model dialog one) is that table sort and pagination can mess up things big time - if the table is sorted alphabetically by a person's name, and the user views entries around the letter Z, and then enter a new user whose name is 'Adam', what happens?
In-place record editors
This has the efficiency (speed) advantage of in-place field editors, but allowing Save and Cancel operation. So essentially, a type of marriage between in-place editors and mini-form.
There are some interaction issues with them, like what happens if neither Save or Cancel are pressed but the user clicks on a navigation item or another records?
Edit mode with inspector panes
Inspectors is the modern name to property editors - a section on the screen showing the selected record data in a form. The form will be in view mode, unless the user clicks Edit, the data can be edited, until the user clicks either Save or Cancel.
The key problem with this pattern is that there are many interaction opportunities on screen while the record is in edit mode - users may forget to press save.
It has many of the advantages of the modal dialog pattern, yet users can see other records while editing.