Page History

{uxstatus:revisit}Not completed yet, missing mockups{uxstatus}

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

h2. Description of desired behavior

[Similar to AdminCentral|Working with items in AdminCentral], in page editing, thean *[Actions sidebar|AdminCentral conceptual overview#workspace]* offers me a list of actions applicable to the currently selected content element. InThis casecould of page editing, this is be either the page itself, or a selected paragraph or an area. 

{mockup}

The sidebar is shown in a column on the right side of the screen (left side on RTL setups). 

{mockup}

The sidebar 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|Showing system messages]. Visually, it takes upreferences the appearance of the header alsoarea visible in AdminCentral and thus seconds into flaggingflag the space on the page dedicated to controls and settings.

The middle part right below the header starts with the list of actions and may also show additional information on the currently selected content element. It is implemented using an [Actions Rack|The Actions Rack], which uses a dedicated unit for presenting and handling actions. [A dedicated page|The Actions Rack] 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.

h3. Collapsing the Actions sidebarSidebar

The Actions sidebarSidebar can be collapsed so it usestakes 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 versionsidebar 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 stillremains visibleavailable as well.

{mockup}

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|The Actions Rack#Use animations to smoothen transitions] and slide the preview up and down instead of abruptly opening and closing it. 

{note:title=Sketch only}The following paragraph is not final yet, but already captures how notifications will work once multiple message services exist.{note}

h4. Show message notifications

If incoming messages arrive or [important system messages wait to be acknowledged|Showing system messages], a notification icon lights up. Since the space available to the header is minimal in the collapsed state of the sidebar, only the icon of the last reporting service may show its icon; the icons of all other message services remain hidden. By default If nothing has to be signaled, the icon of the whats-changed service (represented by the "home" icon in the mockup below) is shown, if nothing has to be signaledby 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 returnreturns to unlit state, but as there are also changes that we want to know about, the whats-changed service then 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.