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.

HTML5 Web App iPad Locking and Response

Having recently built a HTML 5 web app for a client to use on an iPad I hit a couple of issues to do with the slight differences in developing for a mobile device vs developing for the browser. I am not talking about native apps, as I am sure they have ways to deal with these issues. So lets look at the first issue.

Username and Password to Login

First issue is present within each approach but is more obviously irritating on a mobile device. Having to type your username and password again is a pain, but its more of a pain when you have to type it on an onscreen keyboard (and if it is a strong password it could mean switching to numbers and symbols on the keyboard).

It is also different from developing in a browser as usually a browser user leaves the browser open and has it in a separate tab or separate window which maintains the session and means they usually don't have to log back in. On a mobile device it is usually one app at a time so if you leave the app (pressing the home button) then the session is broken and it will ask you to log in again on your return.

Solution

One way I chose to solve this is by using a cookie to store a session variable after the first successful login. 

The web app I have developed uses the mydigitalstructure platform and it does the verification of access to the user. After logging in the user agent is returned an SID (Session ID) which can be appended to any calls to the API in order to retrieve the information. This SID would form the basis of any ajax calls that went into mydigitalstructure. 

So to prevent the user from having to log in again I thought to store this as a cookie on the device using a simple jQuery cookie plugin. This way when the user gets to the login screen I check for the presence of the SID cookie, if it exists and is valid (not expired) then run as normal no need for login, else force the user to log back in. Now the user can leave go into another app and come back and still be logged in. Obviously through the code I can set the expiry of the SID cookie and also set up extra levels of auth if required by the app.

The Lock Button

The other issue I found was the lock button. If the user had the app open full screen, left it for a few hours then came back upon unlocking the iPad the app would not realize it has been 'woken' up until the user triggers an event. This could mean there are new items that have arrived in their job queue, or something had been updated from the screen that they locked on. A client may unlock the iPad looking for new jobs/deliveries see nothing and then lock the app again. 

Solution

Unfortunately there is no way to check whether the iPad has been 'woken' directly from a web app, ie no signal or event is triggered by the Apple product to indicate to a developer something has happened. 

I found a solution here which sets up a timer or a heartbeat which will constantly loop as your app runs, the moment their is a discrepancy between the interval time and the expected time it will trigger a custom function. This seems to work well as now I can use this check for the validity of the SID and check the user is still logged in. I can also update where they left off as other users may have updated records they were working on.