Overview
Critique of the current design
The current design has reached its limits in a number of areas - a separate page describes these problems in more detail. But it has also set landmarks: the green edit bars act like markers for editable elements and they work very well on touch devices. The switch to turn off these bars provides a user with the perfect preview of the page with all its features fully working. In addition, the site can be browsed both in preview and editing mode, which makes it very intuitive to work on a number of pages or sections an editor may be responsible for.
The redesign of the current, preview-based editing into the Visual Page Editing of Magnolia 5 aims at providing a solution for all described problems while retaining all qualities of the existing implementation.
The new interface
The standard interface of Visual Page Editing shows two main sections. Most of the screen is occupied by a preview of the page with the well-known green bars marking the editable paragraphs. A newly introduced actions sidebar on the right of the screen presents all actions applicable to the currently selected item and additional info on the item or the page itself. Examples are a comprehensive page status or an overview over available page versions. The toolbox improves the overall visibility of actions in that it introduces a single location to look for actions. It is flexible and can be extended by modules wishing to add complementary functions or data to page editing.
The new visual page editing is targeting mouse input, but has also been crafted with touch devices in mind. While you can use this interface with a keyboard, Page Structure Editing has been specifically optimized for keyboard input and thus should be the preferred way to edit a page using keys only.
Concepts
Area editing
Visual page editing in Magnolia 5 keeps the edit bars introduced in earlier versions, but solves the cloud of bars by introducing Area Editing. The areas of a web page as defined by the web designer and introduced in Magnolia with STK templating are an excellent starting point to reduce the number of edit bars visible at any one time.
Please refer to the separate page on Area Editing for an in-depth description of this concept.
The Actions Sidebar
Magnolia 5 adds an Actions Sidebar to the page editing interface. It
- it shows all applicable actions available to the logged-in user and defined on the currently selected paragraph or area, or on the page itself. This includes access to the clipboard and undo/redo.
- it is capable of showing additional information on the currently selected element or the page itself
- it shows notifications and provides access to the list of system messages
- it contains a small box configurable by the user to identify the Magnolia instance
The sidebar offers a simple toggle control to switch between the page preview and the editing interface. Additional view options allow to customize what's shown and what not even more. The top-most element of the sidebar visually takes up a theme used in other interface layers and acts as a place to show notifications and for additional controls used to navigate layers. It also offers a close button to leave page editing.
The page edit bar still exists and may still be extended to contain additional, customized controls - the page status indicator is merely shown as a placeholder for such functionality. Other than that, the bar merely provides quick access to the page properties.
The Units
The Actions Sidebar also acts as container for a basically arbitrary (but usually small) number of units. Each unit collects a number of UI elements logically and semantically belonging together, such as a language selector or an element representing the translation status of the current page. Units are used to show additional information or aspects on either the selected paragraph or area, or on the page itself.
The goals of the units concept are:
- to offer a great overview of various aspects of a content element while keeping the interface simple
- to provide a scalable UI solution for adding functionality to pages, areas and paragraphs contributed by modules or future extensions
Adding and removing units
By default, only the unit showing the list of actions for the selected content element is visible. All other units are hidden. A *unit selector allows to select one of additionally available units. Selecting a unit adds it to the sidebar. A unit that has to be added first may also be removed again later.
Uniform and expanding units
A unit may either sport a single-state or a two-state interface. If a unit can provide a short overview of its core settings, but needs more space to show all values, it is dubbed an expansible unit and uses the two-state interface offering both a collapsed and an expanded view. In the expanded view, the unit takes over most of the space available in the sidebar and thus has plenty of space available to show its data. In the collapsed view, usually only a brief overview is presented. If a unit only needs one interface to show its settings, it is called a uniform unit and uses a single-state interface offering only the collapsed view.
Sticky unit views
If a user chooses to see the page history by adding the corresponding unit on one page, then surfs on to edit another page, will see the same unit for the new page as well - the unit selection is sticky. The same holds true if a user expands a particular unit to show a specific aspect of the page. By surfing to a different page, he gets the same aspect of the page he just surfed to.
This is an important concept: in order to check one particular aspect of a set of pages, a user chooses the unit providing it, expands it if necessary, then surfs to all pages that interest her.
The unit showing the list of actions
In order to provide quick, consistent access to actions, the first unit in the Actions Sidebar shall always show the list of actions. While it may scroll out of view, it must remain on top of all units and cannot be collapsed. The unit does, however, either show just the common actions (which is also the default) or the complete set of actions applicable to the currently selected content element. The list of common actions must only comprise commands which are often used, as the name says. Additionally offered actions, which have more of a tool character - such as for importing or exporting a node tree - shall be hidden by default on only be shown on demand to avoid that too many entries confuse the user.
The lower section of the list of actions also contains two action pairs, one for the clipboard and another one to provide undo/redo functionality.
Unit views depend on surroundings
Note that the Actions Sidebar is used by different layers and shall also work similarly everywhere. There may be subtle differences, but the concept of units shall be implemented by every instance and must offer the same functionality everywhere. The set of available units may change, and units for sure are not sticky across layers (only within layers), but other than that the sidebar must be both visually and functionally the same.
Units may show up in any layer supporting the display of racks. As an example, both the page preview and well as Visual Page Editing use a Toolbox which relies on racks. While the units shown in both layers may logically be the same, a unit will want to show edit controls in one case, in an other it must hide them. This implies that units must be capable of showing different views depending on the layer they show up in.
In fact, units may also have to be able to enable and disable their controls based on a user's rights and the status of the page. There must be a way for units to obtain the semantic context of a page they are showing up in, so that they can adjust their views accordingly or choose to show different views altogether.