You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 43 Next »

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 toolbox on the right of the screen presents all actions and edit options applicable to the currently selected item or the page as a whole. 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 modules wishing to add complementary functions 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 configure the Balsamiq Wireframes macro and select the wireframe to show. Learn more

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 Toolbox

Magnolia 5 adds a toolbox to the page editing interface. It

  • it shows all applicable actions available to the logged-in user and defined on the currently selected paragraph, 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 global actions such as undo/redo
  • it contains a small panel denoting the name of the instance as well as the logged-in user
  • it provides more flexibility and scalability for actions and edit options
  • it shows notifications and provides access to the list of system messages

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 status. Other than that, it merely provides access to the page properties.

Racks and Units

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.

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

The default configuration offers at most two racks: one for showing the list of actions applicable to the currently selected content element, one for showing edit options on the same. In both racks, the ubiquitous toolbar unit is available as well.

Edit options are preferences affecting the editing of a content element* by e.g. changing which version, variant or translation is edited. Edit options may also choose to provide a short status on certain aspects of a page e.g. in regard to its translation. Edit options differ from properties found in the edit dialogs of a page or paragraph in that they do not affect the actual content, but merely the editing view.

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 racks.

Uniform and expanding units

A unit may either use 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 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 and thus has plenty of space available to show its data. In the collapsed view, only the brief overview fits in. 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 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 available, then surfs to all pages.

Unit views depend on surroundings

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 global action, namely global 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.

Appearance and functionality of the toolbar rack shall be reminiscent of the space in the actions view reserved for global actions in AdminCentral.

  • No labels