In Place Editing and Embedded Entity Masters
What does this term actually entail? There is an "intuitive" understanding, which suggests that something can be modified in the place where it is current observed without the need to navigate to any other part of the application.
A more in-depth (no pun intended) analysis reveals that "in-place editing" can be defined more precisely, as editing without losing the current context. This definition is broader and while being fully in line with an intuitive understanding, it better captures the essential meaning of the term -- the only real reason "in-place editing" can be preferred is to avoid losing the current context the user is in. The "context" here means whatever is currently on the screen observed by the user.
So, if changing some value would require opening a new page then the user would inevitable be taken out of the current context. Instead, changing the value within the context even if the context needs to be modified (not lost!) would be a lot more acceptable, allowing the user to retain their attention span on the task at hand.
It would seem that there are two variations of the in-place editing, both pertaining to editing of entities that are represented by EGI (either in a grid or card mode).
Users may need to edit an entity instance as a whole -- not just a single property, but multiple properties or a property with dependencies to other ones, where the change could lead to an automatic modification or invalidation of the dependent ones.
Depending on the entity's complexity such editing could either require a full Entity Master to be invoked (this leads to context disruption) or an embedded Entity Master that could be used instead.
A full Entity Master has an advantage of better representing entities with a large number of properties (e.g greater than 10) or complex dependencies (e.g. work order with multiple indirect charges) by fully reusing a window real estate. The latter case (i.e. complex dependencies) require a Compound Entity Master as opposed to a Simple Entity Master that would be suitable for the former case.
Embedding Compound Entity Masters is impractical for obvious reasons -- their embedding would lead to the context modification that is equivalent in disruption to opening it on a new page. However, the main view of such masters, where properties of principle entities are edited, could still be well suited for embedding, and thus should be viewed as Simple Entity Master. This way we reduce the discussion of embedding entity masters strictly to a case of Simple Entity Masters.
The main disadvantage of using a full Entity Master instead of its embedded representation is that it leads to aforementioned "context losing". That is, a user was in a information certain context such as viewing entities on an Entity Centre, and needs to change one of the entities. By invoking a full Entity Master, the user is suddenly taken out of that context into a completely new page without any reference to the previously observable information (such as those other entities in EGI). In some cases this would be alright and even preferred, as in case of entities with large number of properties or complex entities where the convenience of editing is preferred over "not loosing the context".
However, in many cases we could achieve a more fluent (uninterrupted) behaviour by means of embedding an Entity Master in pace of the entity's representation in EGI in response to user's edit action. The *embedding process should be accompanied by a smooth transition animation such as this (works only under Opera or Chrome(ium)) that would further facilitate smoothness of the context modification.
An alternative approach to "embedding" of an Entity Master by expanding a table row, is to use a dialog with edges aligned to the nearest row divider and table edges. More specifically, the left border of the dialog should be aligned with the left border of the table, and the top border of the dialog should be aligned with the top border of the row being edited. The top border of a dialog that represents an entity just being created should be aligned with the bottom divider of the heading row.
This alternative embedding approach has a clear benefit when it comes to wide grids that require horizontal scrolling. It can always fit into the page width by following responsive layout settings that are defined for a corresponding master. Also, dialog driven embedding fully corresponds to in-place editing of individual properties that also use dialogs as discussed further in the text.
In order to differentiate between full and embedded modes of entity editing it is proposed to use term edit in reference to editing an entity on an Entity Master that gets opened on a separate page, and term quick edit in reference to an embedded Entity Master representation. These two editing modes can be expressed on every Entity Centre as tow separate actions -- edit and quick edit respectively.
Please note that even in case of very simple entities with 1-3 properties, which can always be conveniently edited in the embedded mode (aka quick edited), it still makes sense to retain the ability for a full mode in order to enable users opening Entity Master on separate pages for later reference. Although, developers should be able to specify which mode should be the default one for each entity. For example, simple table codes such as fuel types should by default be created/edited in an embedded mode, while more complex entities such as work orders and vehicles, which are represented by Composite Entity Master, are better off having the full mode as the default.
Default editing modes may differ between devices. For example, for mobile devices, due to a very limited screen real estate, it might be preferable to use the full mode instead of embedded by default, which would allow better utilisation of the available screen size.
Below is a sketch of an Entity Master in the embedded mode for a desktop device were an EGI row was transformed into a panel representing the master in its desktop layout.
Entity Masters for entities that have one-2-one and one-2-many associations are usually represented by Compound Entity Masters, which have their own menu structures providing access to reviewing and editing facilities of those dependent entities. The master entity, which governs all the dependent, is accessed and edited from what is generally referred to as the "Main" menu item of such master.
This "Main" menu item is effectively opens up is a Simple Entity Master that is designed specifically for editing of properties of the master entity. This Simple Entity Master main view should be used for embedding if a quick edit action is invoked for an entity that has a Compound Entity Master.
A question may arise as to whether the layout for an Entity Master in full and embedded mode should differ. The answer is no. The same layout for the same device should be used in both modes. This will contribute to better user's association between two different representation of the same entity.
Often there is a need to edit individual entity properties as opposed an entity as a whole. In such cases bringing up or even embedding a fully fledged Entity Maser might be inconvenient from the user perspective. The user just want to tap the value and start changing it.
For this, an in-place (aka inline) editing should be enabled per individual property. We already use a similar approach for status change on DDS in Trident Fleet where a dialog comes up with an editor for a single property "note". Similar, but more elegant approach needs to be developed as a generic facility (functional entity with view). X-editable offers a very reasonable approach, which could be used for an inspiration. Google Material Design offers guidelines regarding the table design in general and in-place editing in particular.
A very cool thing is that a proper entity editing model can be used in this case too. So, there is nothing special in editing an individual entity as compared to editing an entity from a fully fledged Entity Master.
There could definitely be cases where modifying a single property would lead to invalidation of some other properties, which are of course not included as part of a single in-place property editor. In order to further improve in-place editing UX, there should be an action (button or link) as part of the in-place editor that would open up a corresponding Entity Master either in embedded or full mode. This way a user could easily transition to a more appropriate editing facility allowing them to correct any reported validation errors.