Child pages
  • Working with page content and the page itself
Skip to end of metadata
Go to start of metadata

Ready for implementation

Story

If I select a content element on a page I'm currently editing, Magnolia presents me a list of common actions I can execute on it. With these, I can add new elements, edit the element, move or delete it, etc., if I have the necessary rights to do so. I can also retrieve a list of all actions defined on my element, but it's the common actions which are visible by default.

Magnolia also offers me additional information a selected content element if available and if this makes sense in the current context. I could get to see comments attached to a particular paragraph, a list of changes applied on the current page or understand whether all content has already been translated into all required languages since I checked the last time.

Description of desired behavior

Similar to AdminCentral, in page editing, an Actions sidebar offers me a list of actions applicable to the currently selected content element. This could be either the page itself, a paragraph or an area.


The sidebar is shown in a column on the right side of the screen (left side on RTL setups) and has three distinctive parts. The header at the top shows the Magnolia logo, but is mainly used to signal notifications for waiting or missed messages such as errors or warnings. Visually, it references the appearance of the header area in AdminCentral and thus seconds to flag the space dedicated to controls and settings.

The middle part right below the header starts contains both the switch to change between editing the page and its preview, as well as the list of actions. It may also show additional information on the currently selected content element. This is implemented using an Actions Rack, which uses a unit for presenting and handling actions. A dedicated page contains detailed descriptions on how the list of actions and other units behave and work together.

Finally, the lower part of the sidebar just above the bottom edge consists solely of a batch showing a configurable name and color. The batch helps a user to quickly identify the Magnolia instance she's currently working on.

Collapsing the Actions Sidebar

The Actions Sidebar can be collapsed so it takes up less space. When collapsed, only icons for the common actions as well as for copy&paste and undo/redo are visible. This toolbar-like sidebar also contains a simplified header just large enough to contain a message notification icon. A simplified badge without the name but featuring the same configured background color is remains available as well.


Care must be taken to ensure that changing from the expanded view of the sidebar to the collapsed one does not disorient and confuse the user. Use the animations to smoothen the transitions as defined for the Actions Rack and slide the preview up and down instead of abruptly opening and closing it.

Sketch only

The following paragraph on message notifications is not final yet, but already captures how notifications will work once multiple message services exist.

Show message notifications

If incoming messages arrive or important system messages wait to be acknowledged, a notification icon lights up. Since the space available to the header is minimal in the collapsed state of the sidebar, only the last reporting service may show its icon; the icons of all other message services remain hidden. If nothing has to be signaled, the icon of the whats-changed service (represented by the "home" icon in the mockup below) is shown by default.

//mockup showing how the collapsed sidebar shows a notification

If the user visits the service currently showing its icon and thus checks the newly arrived messages, he resets the icon to unlit state. The next service requiring to signal new messages may then show its icon.

//mockup showing the example below

As an example, let's assume there is one error waiting in the system messages list and two items I'm watching for changes have actually changed. The system messages service goes first and shows its icon signaling the error. The user clicks on it and is [taken to the list of system messages|Edit a page using its preview#Notifications and messages
] where he acknowledges that he's seen the error message. The icon returns to unlit state, but as there are also changes that we want to know about, the whats-changed service shows its icon signaling the two changes it has detected. If the user also acknowledges these, no notifications remain. The header finally shows the unlit "home" icon.

  • No labels