How many Modal's is too many? Do user's like windows within windows?

Starting a new web application project from scratch is a great way to re-assess the standard UI elements and structure that leads to how your users interact with the end product. I personally have always wondered how each UI element has been essentially typecast into different roles within the user experience.

Is the modal under utilised in app development?

For example the modal UI element is supposed to only be used for simple confirmation, forms or alerts as they usually operate within a small window and are used to obscure the background information from the user. Why is it that the modal is limited to such use? Is it possible to have an easy to use app that has modals within modals?

Modal's within modal's or is that crazy talk?

It is definitely programmatically possible to have an infinite number of modals nested within each other, the same way you can have an infinite number of pages/views in your app.

So why is having different pages/views considered better?

When you have a new page your user transitions away from the content they previously were connected with and now are focused on the next content. The concept is based around that the user is moving towards an end goal, so showing a modal for each step along the way would clutter the screen but also make it seemingly complicated to back out to the previous step.

Your user's don't want to feel like this is their workspace.

Sometimes, however you might not want to send your user to a new page as they will loose focus on what they are doing. They might be creating an object that has other objects attached to it, for example an order with line items. You might elect to pop up a modal when the user is adding an item to an order as they are still in context with the order. If you were to send them to a new page purely for adding line items they may feel disconnected with the initial order object, by using a modal you are 'nesting' the window within the order object and allowing the user to continue updating the order object.

The other option for this case is to still maintain the connection would be to dynamically update the UI when a user presses 'Add' or 'Edit' line item, so no modal is used and the user still is connected to the object. They are just simply loading in the related content as they traverse the page of the app. This is the best option but sometimes if designing for mobile devices there is not enough screen estate to do so without it looking crowded.

It is a case by case basis where modal's are relevant, (just like with every other design choice) the user is the ultimate deciding factor as they may be more comfortable with having multiple windows on screen at once knowing that with a few closes they are able to get back exactly where they started without changing pages/views.

Modals, Edits and oOjects

Have been looking into standard objects (contacts mainly) and editing lately and have been wondering when it is best to use Modals, or Windows vs actually pushing content into a new viewport in page. Most of these approaches tie into the development widgets at Kendo UI for Web and are quite different in their approach.

Take this instance of editing a contact, a user would obviously want to search for the contact first most interfaces handle this the same way, but after they select the contact they wish to view or edit the attributes of said contact. This is where the similarities end and different interface designs take place.

Kendo UI Inline Edit

Some allow you to edit directly from where you searched inline. 

Inline Edit is great for data sets where the user only really needs access to a few fields to edit the table directly and this increases speed of users edit. However, this also means the user hasn't really established a direct view connection with the object (row) in question and may feel like they are simply editing an excel table. Also if you start having more then 5-6 fields the user can get lost quite quickly editing from left to right to complete the row. I think users would prefer a long page with a lot of elements then a wide page where the fields are listed left to right, harder to read. All in all good for maybe product price adjustment lists which don't have many fields and allow you to edit but for a contact which has lots of data not really user friendly.

Kendo UI Popup Edit

Others may use a Popup Edit Modal.

Popup Edit allows the user to actually enter a view for the object in question where they can edit the data. This edit view can be presented differently from the standard search view and will make the user feel as if they have 'opened up' the object in question. This means that your search view can be really simple and can avoid having lots of text as the editing is not done inline. 

This however, can fall apart, if you have a variety of object links in context to the current object. For example "I have a contact which has actions linked to it, in the edit modal, I would like the user to be able to view the actions in the same modal" having this in a window could create confusion with the user as they could open the modal at the contact search screen, but lose context as they navigate across to the action object. If you are going to use a modal for editing an object it cannot be too complicated, should be a single screen should avoid cross object issues. If you want to create a view where a user can view a contact and all the actions they have linked then it should probably be part of your contact view, not the edit screen.

Custom Edit Screen

A Custom Edit screen can be created and is probably the approach of choice in most situations and is the most popular. These usually mix in read only structure with editable fields, this allows the user to have a nice view of summary information about the object and also a separate area for editing of details, all of this is contained in the same view of the object, just containing specific areas for edit.

The approach also allows for cross object linking so a user could navigate from a contact to a linked action and change object views without being confused as to where they are in relation to the objects they are working on.

Overall

These approaches are definitely not the only ones available as a developer but I think it is worth having a look at each, it all relates back to your audience and what the users are looking for in the app. Custom Edit is obviously the most used, but in some cases an inline or window might be best for the user.