One of the key usability problems with AdminCentral in previous Magnolia versions is the lack of preservation of context or interface state when switching between view. If you edit a page, then quickly change to the DMS to add a document you'd like to offer for download, then switch back to the website menu, you'd have to find the page again you were just editing.
In Magnolia 5, context between view switches is preserved. This is done by saving the state of the user interface and restoring that state once a view becomes visible again.
Rules and restrictions
In order to ensure consistency of data shown in views and to guarantee a deliberate use of available resources, state can't be saved forever. This section names a number of rules and restrictions for any state-saving framework used to realize the preservation of interface context. Please refer to the conceptual overview of AdminCentral, if you need more information about a particular UI element.
Context is preserved _whenever you switch from one view to a different one, in particular:
- if you switch from one view type to another (e.g. "structure" to "page list", "list" to "thumbnails")
- if you switch views within a workspace by switching between asset type tabs (e.g. "videos->thumbnails" to "images->list")
- if you switch views by changing to a different menu item or sub menu item inside the same work area (e.g. "configuration->modules" to "configuration->server" or "tempting")
- if you switch views by changing to a sub menu item or menu item of another work area (e.g. "content work area->website->pages->page list" to "personal work area->work items" or "settings & tools work area->tools->packager")
- if you launch a basic or advanced search (search returns you to the original view once you exit)
- if you exit AdminCentral for another layer.
In order to guarantee the consistency of a workspace and its views, the following set of rules must always hold true:
- A view is updated either immediately or when becoming visible again with changes made in the same or another workspace, even if it currently invisible.
- All settings of a workspace such as the state of its controls (asset type tabs, view selection, sorting and grouping options) are preserved and re-applied, if a workspace is updated
- Likewise, the currently focused item and all selected items in every view of an updated workspace must remain focused and selected.
- The set of items shown in a view must be current and should reflect all changes made in the same or a different workspace.
In essence, this means that the query that has been executed to show a particular set of items in a view is re-executed either immediately or when the view becomes visible again.
In case a change applied in the same or another workspace causes a conflict with the preserved state of a view, these rules are used to resolve it:
- If the focus has become invalid, it is either removed or moved to the default item of a view.
- If the selection of an object has become invalid, it is removed. Additional selected elements stay selected.
- If the set of items shown in a view is large and only an excerpt of it is shown, the position of the scrollbar relative to the total number of items should remain the same before and after an update. If this can't be guaranteed or is impractical, the excerpt should show the first selected item at least. If no item is selected, it should show the item that has the focus. If no item has the focus, the view shall jump back to the top of the set of items.
It doesn't make sense, is actually not desirable and a waste of resources to preserve context forever. The following limits are therefore imposed:
- If the current browser session ends, e.g. due to a timeout or the user logging out or closing the browser window, all context is freed.
- Context is only preserved for the last n number of views.
The number n should be configurable; a good default might be 5. This would result in only the context of the five ten views shown being preserved.