Ready for implementation
A rack is basically an enclosure for mounting multiple components. 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 controls logically and semantically belonging together.
In Magnolia, the purpose of units is to show actions as well as additional information or aspects on a selected content element, while the purpose of a rack is to consolidate all available units in one place. A rack could show all versions and the change history of a page in one unit for each. A rack could also provide access to a particular image asset by offering one unit for actions, one for providing details on the image format and a unit showing comments added by users. Additional examples for units could be a unit giving an overview of the translation status of a paragraph and a unit offering just a language selector to switch between localized versions of a page.
The goals of the racks and units concept are:
- to offer an overview of various aspects of a content element while maintaining a web-like, easy to use and simple interface
- to provide an extensible UI concept for modules to add their functionality pertaining to the currently selected content element to the existing interface
- to do both while supporting different screen resolutions, mouse and keyboard input as well as touch devices
Racks and Units
Adding and removing units
A rack may contain a pre-configured set of units. It may also offer additional, initially hidden units through a unit selector. Selecting a unit using the unit selector adds it to the rack. The new unit is positioned at the end of all units available, shifting them up if required. The rack shows a vertical scrollbar if there's not enough height available to show all units. The user has to scroll to access all units. Note that a single unit UX:could also be maximized instead.
A unit that has been added may also be removed again later by clicking on its close button. Some pre-configured units may be non-removable, but if a unit can get added, a user must also be able to also remove it again.
Maximizing a unit
Any unit in a rack may be maximized to cover the entire space available to the rack. In such a case, the rack must make it visually clear that it is currently showing a particular unit only, but that other units are still available if that unit get minimized again.
Maximizing a unit is a neat way to check one aspect of a series of pages. If you're interested in the translation status of a number of pages, add the unit providing you the translation status overview, maximized it so you don't have to scroll to it every time, then surf to all pages you're interested in - the unit shows all you want to know, since UX:units and their view states are sticky.
Units and their view states are sticky
If a user chooses to see the page history by adding the corresponding unit on one page, then surfs on to edit another page, she will see the same unit for the new page as well - the set of visible units is sticky within a single layer. The same holds true if a user UX:maximizes a particular unit to cover all space available in the rack. By surfing to a different page, he gets the to see the same unit maximized again. So the view state of a unit is sticky within the same layer as well.
A unit has nothing to show
If the currently selected content element changes and a unit has no data to show on it, it shall show a default message indicating that. It isn't simply hidden, but remains visible.
The following definitions ensure that:
- notifications can be shown
- are actually noticed
- and can then be viewed quickly and easily.
If any UX:unit would like to signal a problem using a warning or error message, it either does so immediately if the unit is visible or by employing the UX:unit selector to signal a notification. Opening the combo box will then show which unit reported the problem. Selecting that unit will add it to the list of units shown in the rack and thus makes the actual message visible.
If the user directly clicks on the notification icon of the unit selector instead, the first unit reporting a problem is shown and maximized at the same time, thereby putting the focus on the problem immediately.
Building good racks
There may be a unit, which shows the current page status. Another unit shows the actions available on the currently selected paragraph, area or page. Is it ok to mix and match these units in one rack? This largely depends on what you intend to present in the rack and how you present it. It might be perfectly natural in a page editing interface to show paragraph actions along with the overall page status in the same spot.
The following guidelines should help to build good racks:
- Use a single rack per interface.
Don't stack racks, don't put them next to each other. If you have to use multiple racks, put them far apart.
- Keep the number of units per rack very small (at most five).
If you have to offer more, maybe you should consider to develop a specific interface for the task at hand instead.
- If you mix different types of units, make sure the titles are clear and refer to the element they connect to (e.g. "paragraph actions" and "page status", not simply "actions" and "status")
- Show as few information as possible in a unit and group it properly.
If you have to show many things at once, consider to develop a dedicated interface for this. A rack is probably not the good place to show the activation state of the page in all 25 sites you manage.