...
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 toolboxactions sidebar on the right of the screen presents all actions and edit options applicable to the currently selected item and additional info on the item or the page as a wholeitself. Examples are a comprehensive page status or an overview over available page versions. The toolbox improves the overall visibility of actions and edit options by providing them with both a clear location on screen and enough space to present their interface. It introduces flexibility and scalability to support current and future 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 still 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.
...
Please refer to the separate page on Area Editing for an in-depth description of this concept.
The
...
Actions Sidebar
Magnolia 5 adds a toolbox 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, selected area or on the page ifself
- it hosts a set of edit options of the currently selected element to e.g. select a specific version or language of a page
- it offers access to copy&paste itself. This includes access to the clipboard and undo/redo.
- it contains a small panel denoting the name of the instance as well as the logged-in userit provides more flexibility and scalability for actions and edit optionsis 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.
Page edit options like a language selector or information on page links have been extended and moved to the edit options rack. The button to return to AdminCentral has been replaced with a button in the Toolbox to leave page editing, which is also where the "Preview" button was moved to. The page edit bar still exists and has been extended to also show a quick page statusmay still be extended to contain additional, customized controls - the page status indicator is merely shown as a placeholder for such functionality. Other than that, it the bar merely provides quick access to the page properties.
Racks and Units
The Units
The Actions Sidebar also acts as A rack is basically an enclosure for mounting multiple UI modules. In Magnolia 5, a rack is a 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 racks and 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
Actions and Edit options rack
Adding and removing units
By default, only the unit The default configuration offers at most two racks: one for showing the list of actions applicable to for the currently selected content element , one for showing edit options on the same. In both racks, the ubiquitous toolbar unit is available as well.Anchor
Currently, only page edit options are defined, but they may become available for paragraphs and areas as well should a need arise.
More space in a rack
If many actions or edit options have to be shown and the space for showing them is not available (e.g. on small screens), the rack may virtually split and offer more than one page effectively multiplying the space available for units. The rack then shows a page switcher control for accessing all pages. Note that the control shows up above the toolbar unit, which remains visible on all pages of all racksis 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 use 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 expanding 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 rack sidebar and thus has plenty of space available to show its data. In the collapsed view, usually only the a brief overview fits inis 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 show the page edit options, then moves to a different page, the page edit options of that page are displayed 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, chooses the collapsed or expanded view, if availableexpands 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.
The toolbar unit
The toolbar is a special unit hosting undo/redo. Undo/redo needs to be available independent of any currently selected content element. The toolbar thus is available at all times and at the exact same location. It even remains visible if a unit is switched to show its expanded view.