Validating a Preferences/Configuration "app"

Question

I have a system configuration / preferences "app" I'm designing as part of a larger browser-based application. Our overall application has "apps" (like a development app, a user management app, a catalogue app, etc) of which this is one.

This system configuration app is (behind the scenes) one giant configuration object broken up into several logical children, each of which is represented by a left-side menu (example: 'general configuration', 'database configuration', etc). Basically each side-menu contains a reasonably complex form (grids, tabs, etc).

There can be several of these configurations, and the user can choose which to edit using a drop-down at the top of the page (named "configure").

My question is, what is the most logical/reasonable/expected way to handle saving and validating this app? Given that the "save" api is (behind the scenes) universal to the entire app contents?

Options I've considered:

(1) save the entire object. If the user navigates through the side-menus, when they leave their changes are preserved. If the changes are invalid, the user is informed via warning, when they press save they are informed there are validation errors in tabs that aren't currently open.

(2) save each side-menu "sub object". If the user navigates through the side-menus, they are informed that their changes will be erased (if they made changes).

We normally validate fields as the user blurs out of a field, but there may be more involved server-side validation happening as well.

*Note: these side-menus are used in other apps in our application, as is the "action" bar (where save is located, marked in blue). In some apps, they clearly require to save before leaving the sub-menu.

Here is the app:

^{download bmml source – Wireframes created with Balsamiq Mockups}

Answer 1

Here are some recommendations related to saving and validation that will help users in a complex scenario like this.

• Feedback on errors should be displayed as immediately as possible. If you can validate client side then do so. I appreciate that some errors may only be detectable on the server side (this is fine), but don't make a user wait until the submit button is pressed for feedback on all issues. Doing it inline where possible will help users get through the process faster.
• Feedback should be displayed as close to where the error occurred as possible. This is simple with client side validation errors where you know the user is on the same screen as the error. It becomes somewhat trickier when you have multiple screens / different sections, and the error is not detected until the user clicks save. I would suggest going in the same direction as a lot of IDEs, and display a panel containing a list of issues. This list provides the user with an overview of all issues, and can be navigable (i.e. a user clicks on the issue to navigate to the relevent section / field) to help them quickly find and solve them. The panel should be easy to spot (beside your save button would be logical), and visible on every screen.
• A user should not lose any work if something goes wrong. If you have multiple screens and a save fails, you need to make sure all the user's work so far is persisted.

To do the above things you will need a mechanism to save the state of incomplete / incorrect configuration objects. (This somewhat goes against the web browser paradigm, which is stateless.)