Table of Contents

Concept

Data Model

Every software application is designed to reflect a specific set of application domain objects, the domain model or  data model of that application. When implementing this model in a programming language like Java, it is transformed into specific types (classes, interfaces) which reflect this data model technically. The technical data model is not to be discussed here, but instead the data model that the user experiences when working with the content management system. So, when we speak about the "data model" here we refer to the model - the "picture" - that the user draws in his mind to help him understand how the application works.

Obviously, the better the user can perceive the data model of the application, the easier (and more efficient) he can work with the system. One way of making the user draw his "in-mind picture" of the application is to write a lot of documentation (that the user, of course, has to read) which explains him how the application works. Another way (for the user as well as for the developers much faster way) is to simply let him experience the application model himself by mapping it through the graphical user interface. To do that mapping between the UI and the data model properly we, of course, have to know how the application domain's data model looks like.

This section describes the data model of a typical content management system (using as far as possible the vocabulary used in Magnolia).

The Website/Content Repository Hierarchy: Pages and Contents

The most important elements in the data model of a web content management system are pages and content. Users create pages and content on those pages.

Pages:

• organize information in a structure or hierarchy (which builds the navigational structure of a website)
• hold a set of contents which represent the information on those pages
• have a view that represent them visually

Content

• hold the actual information/data
• have a specific type that represent them technically (generically like text, image, video, etc. or more specific like news, product etc.)
• have a view that represent them visually

Differentiating Definitions and Instances

To concretely specify a page or a content we need a definition of those. We say that a page instance is built according to a specific page (type) definition. Simultaneously, a content instance is built according to a content (type) definition. The relationship between definition and instance is one to many: a single definition can have multiple instances, whereas an instance has exactly one definition.

In a content management application the definitions are created by an administrator (referring to the roles here), instances of page definitions are created/edited by content managers and instances of content definitions are created/edited by content editors. (You could say it the other way round as well: a content editor is a person that creates/edits contents; if someone creates/edits a page he is in the content manager role.)

Definitions and Instances in Magnolia

In Magnolia the page definitions are referred to as "template definitions" or simply "templates". (Yes, this is confusing since also content definitions contain a "template".) And content definitions are referred to as "paragraph definitions" or simply "paragraphs".

Moreover it gets even more confusing since there exists something referred to as "pages". Currently, "pages" in Magnolia are a replacement for controller servlets for specific functionality that is required by the Admin Central (e.g. there is the "DialogPage"). These could have been better named with something like controller definitions or controllers.

The alignment of those names is suggested with the realization of the feature "Template, Paragraph and Dialog Improvements".

A dialog definition or simply dialog specifies which controls appear in an application's view. In most of the cases those views are input forms.

The Relationship Between Pages, Paragraphs, Dialogs and Templates

Note that we use the previously introduced names for the concepts not the Magnolia ones here. So "template" in this case refers to the template resource (or the configuration that contains a link to this template resource) and "page" refers to something that in current Magnolia is a "template definition".

Relationship Between Pages and Paragraphs

Typically, on a single page instance exist multiple content collections and each of them contains multiple content items. Within a specific content collection an editor can place paragraph instances of a certain set of paragraphs. Let's call this set a paragraph collection. So, to say it simply, a paragraph collection specifies a set of paragraphs which can be placed in a content collection of a page.

Currently the concept of paragraph collections doesn't exist in Magnolia explicitly. However, as this has some disadvantages in the feature "Template, Paragraph and Dialog Improvements" it is suggested to introduce this as a well defined concept within Magnolia.

Relationship Between Paragraphs and Dialogs

To create a content (an instance of a paragraph), the user puts in the data into a form which is specified by a dialog definition or simply dialog. Actually, to put in data one does not necessarily would have to provide a dialog definition. This could for example also be done by an XForm which (implicitly) defines a dialog in code. However, this is currently not possible with Magnolia. The dialog definition can be seen as mapping that maps properties of a paragraph definition to UI components.

Unfortunately, in the current Magnolia implementation the dialog definition does not only define how to map properties to controls but also (implicitly) defines the actual model of the paragraph.

Improving this is also a topic of the feature "Template, Paragraph and Dialog Improvements".

Relationship Between Pages/Paragraphs and Templates

Both, pages and paragraphs have visual representations which (in the end) are realized in code in terms of template resources or in short a templates (e.g. a JSP or freemarker file). However, one could separate concerns even more: a template is not just a template resource but is made out of a layout and style part. A page type can be arranged in different ways (layouts) and can have different styles independently of the applied layout. In such case a single template resource would implement one (or possibly more, using some conditional logic) specific layout. A style is normally implemented in terms of a Cascading Style Sheet (CSS).

The separation of layout and style is most likely too much for the current status and thus separately covered in the Feature Separating Layout and Style (1)feature "Separating Layout and Style".

Multiple Instances & Activation: Author and Public

A typical Magnolia installation typically consists of at least two web application instances:

• Author instance
  The author instance is used to actively manage the content of a corporate site and is the main instance within a deployment of the Magnolia CMS. Content put into that instance will be activated (published) to subscribed public instances upon review by managers. In most cases there is only one author instance configured in a deployment scenario.
• Public instance
  The public instance expose the corporate site's content to the World Wide Web. The instance is not accessed by editors or managers directly but instead by visitors of the website. It is quite common that there exist multiple public instances subscribed to the same author instance within a single deployment scenario.

There are several reasons why a deployment consists of multiple instances:

• Staged content publishing
  Often managers want to review the content created by editors before publishing them to the live site. This is why editors edit the contents on a completely separated authoring instance and managers publish them (once approved) to the
  public available instance.
  Typically there are only two stages: the editing stage and the live stage. The author instance represents the editing stage and the public instance(s) represent the live stage. However, in theory it would be possible to map more than two stages to Magnolia instances. For instance a deployment scenario could also consist of a quality assurance stage between editing and live stage. In that case one would install two author instances and one ore multiple public instances. Pros and Cons of that approach are out of the scope of this document, however it is fact that there are arguments for (as well as arguments against) such an approach but with the current application design (see [Metaphors & Basic Concepts]) it would be a nightmare to configure such a deployment infrastructure.
• Fault tolerance/Performance
  For fault tolerance and performance reasons it is quite usual to set up multiple public instances on different physical machines to gain application performance with the help of a load balancer. Magnolia supports those deployment scenarios by allowing activation from a single author instance to multiple public instances (and even to other author instances).

Illustrations

Security Subjects: User, Group and Role

TODO

Metaphors & Basic Concepts

Admin Central

The Admin Central is the management application for the Magnolia CMS. Every participating role (editor, manager, administrator, developer) performs several tasks within this application. It can be seen as the single entry point for performing content management with Magnolia.

Suggested enhancements of the Admin Central metaphor compared to the current version:

• see Feature: Single Admin Central for Multiple Magnolia Instances
• see Feature: Dashboard

Illustrations

Actions and the Function Bar

A basic concept of Magnolia is the use of actions. An action is associated with different subjects for those it can be applied. On the other hand every possible task that can be applied on a subject is exposed to the UI in terms of a action button or context menu item.

Suggested enhancements of the concept of actions compared to the current version:

• see FeatureActions
• see FeatureFunctionBar

Templates, Paragraphs and Dialogs

One of the most important concepts in Magnolia is the concept of Templates, Dialogs and Paragraphs (looking at them as a single, combined concept here). The concept has clearly been proofed successfully, however from user's perspective it lacks some semantic consistency which I will try to explain below.

The following drawing shows the relationship between Templates, Paragraphs and Dialogs: 

TODO

Related to: 

• see FeatureTemplateParagraphDialogImprovements
• see FeatureSeparatingLayoutAndStyle

Dialogs

See the separate Dialogs page. 

Editing Content: Hierarchical Editing vs. Editing in Preview Mode

Hierarchy Mode generic (template independent) keeps/shows navigation context faster for advanced users allows searching/filtering allows drag & drop of content between pages of documents/data from resources to page might lead to a very big tree

Preview Mode best mapping for end-users works with JSP templates only navigation/page structure (at least currently) not editable complicated layout makes page editing difficult, can be simplified by using cms:adminOnly tag pollutes templates probably does not work well with AJAXed paragraphs depends on template, e.g. removing a <contentNodeCollection> makes content unaccessible

Draftsdsdfsdf

URIs and virtual URIs

In Magnolia there are a lot of concepts that are directly or indirectly related to URIs. They are related to URIs in a sense that they e.g. identify a resource or trigger the execution of some action or check. Specifically the functionalities are:

• website pages
• I18n support (at least with DefaultI18nContentSupport)
• virtual URIs
• URI2Repository mappings
• servlet mappings (via servlet filter or web.xml)
• filter mappings/bypasses (via Magnolia managed filter chain or web.xml)
• URISecurity
• default URI
• activation subscriptions
• cache (via URIs/voters)

Problem
All those concepts add essential features and opportunities to the Magnolia CMS and give developers powerful configuration and customization options. However, in the current Admin Central it requires quite detailed knowledge of the Magnolia programming model to come up with all those features and furthermore the different configurations are a common source for errors or unexpected behavior which are once occurred hard to identify.
Example: say a website editor creates a page named "welcome" on the root and an administrator creates a virtual URI mapping that maps "/welcome" to another page. Most likely the editor will need some time to figure out why he can't access the page via "http://host/magnoliaAuthor/welcome" or he will not recognize that at all and the error will arise at some point when the page is already published. Specifically the problem is that the concept of mapping the website hierarchy to URIs intersects with the virtual URI mapping feature which, for the editor or a Magnolia newbie, is not made obvious at all.
Another example: did you know that you cannot name a page on the root "data" if you have the Magnolia Data module installed?

Solution
One possible solution for this would be to show/indicate most of the URI related concepts in the website hierarchy (website tree). The following table shows a possible indication of the functionalities mentioned above in the website tree:

Feature	Indication	Comment
website pages	normal page icon
I18n support	icon indicating the entry point for a language version	if indication is possible or not is implementation specific
virtual URIs	link page icon
URI2Repository mappings	resource container icon
servlet mappings	service endpoint icon	only applicable for prefix mappings resolved by servlet filter or web.xml
filter mappings/bypasses	filter symbol as icon extension	can appear on every node in the tree resolved from Magnolia managed filter chain or web.xml might be to much information since every URI is filtered should be configureable for which filters an indication is displayed only applicable for prefix mappings can be shown through Feature Masked Views
URISecurity	lock item for secured pages	is resolved from anonymous role and URISecurity filter bypasses can be shown through Feature Masked Views
default URI	home symbol as icon extension	appears exactly once in the website hierarchy
activation subscriptions	(background) color indication	should only be shown in combination with Feature Masked Views, otherwise it is an information overload
cache	cache (e.g. clock symbol or green bulb) symbol as icon extension	can appear on every node in the tree is resolved from configured cache URIs (and possibly cache voters) or alternatively by requesting the cache key for each node

This solution is covered by the Feature Additional Website Hierarchy Responsibilities.

Features

The following section lists the new or at least "to be discussed"/enhanced features. The numbers in parenthesis define the priorities where (1) is lowest and (5) is highest.

Category: General

Feature: Customizability (2)

Most obvious things will be customizable:

• list/tree control state:
  • column order

• • column width
  • column sorting
  • opened node

Additional customizations will be marked explicitly in the feature's description. 

The scope of the customization is either:

• at least session scope
• preferably persisted with user preferences
• optionally: customizable per role

Post-it #6

Feature: Skinning Support (1)

Idea: allow customers to apply another skin to the Admin Central.

TODO

Post-it #33

Feature: Keyboard Support (4)

Depending on the used client-side technology we will introduce keyboard shortcuts for (ordered after priorities, descending):

• form navigation with tabulator
• dialogs (save, save-on-enter, abort, etc.)
• actions (new, activate, etc.)
• control navigation (tree traversal with arrow keys, next/previous tab, etc.)

Post-it #4

Feature: Drag & Drop Support (4)

TODO
define what can be dragged (and where it can be droped)
define unique drag indication (highlight)

Post-it #32

Feature: Single Admin Central for Multiple Magnolia Instances (2)

Problem
As stated before, the Admin Central is the single entry point for Magnolia users. However, a typical Magnolia installation typically consists of more than one instance (in most cases one authoring and multiple public instances, see [Multiple Instances & Activation: Author and Public] for more details) each one deployed with its own Admin Central instance. Thus, there actually is no single entry point anymore which leads to confusion for users and especially for administrators.

Solution
Provide a single, completely decoupled and standalone web application that is able to manage multiple Magnolia instances at once. This makes the user's view to the underlying application model more transparent since a real single entry point to the complete Magnolia application is available and easily to communicate.

Consequences
There are several impacts that should be considered when discussing this feature:

Pros:

• abstraction from deployment infrastructure: administrators can edit each instance's configuration through a single interface hiding the fact that several instances exist on different machines at different locations
• UI customizations are preserved over all instances
• the Admin Central application's life-cycle can be managed completely different: updating the Admin Central web application does not necessarily require updating the Magnolia instances and vice versa. The Admin Central can even be completely replaced by another application client.
• a single Admin Central would even allow batch processing of tasks over multiple instances or drag & drop between instances
• separating the Admin Central application could greatly simplify the security configuration of both, the Magnolia instances and the Admin Central.
• separating the Admin Central does not prevent from having a one-to-one relationship between Magnolia instance and administration UI

Cons:

• might be technically difficult: e.g. editing in preview mode is not coupled to Admin Central any more; Admin Central would have to aggregate the preview editing mode from the Magnolia author which might cause problems due to the fact that both applications run in different servlet contexts
• requires RPC/Webservice-like access to Magnolia instances

Variations

• Variant I: explicitly manage working instance; select instance on login; during the complete session the user is working on the same instance and is only able to access that instance's data
• Variant II: explicitly manage working instance; allow switching the instance from within Admin Central; during a session the user can switch to another instance
• Variant III: implicitly manage instances; completely hide multiple instances and synchronize them fully automatic, only show them in the case of errors via messages or status indicators
  This requires Feature Automatic Publishing, also useful in that scenario Feature Masked Views

Drafts

 

Post-it #1

Feature: Advanced Search (5)

Provide a generic way to find anything in the Admin Central.

Considered resources for searching:

• workspace
• node type (depending on workspace selected)
• specif node property/properties; also adjust selection depending on node type (e.g. use a boolean selector if node data type is boolean)

Supported operations:

• contains (full text search)
• "all criteria match" (and), "one criteria matches" (or)

Additional features:

• save searches/queries

Post-it #37

Feature: Dashboard (1)

Description
The dashboard is the entry screen of the Admin Central. It provides the user direct entry points to his most important features or locations within the application and thus the most important information at a glance. The dashboard is fully customizable to take respect of the user's role or preferences. The dashboard is composed of several widgets which provide different functionalities. Using widgets the dashboard functionality remains easily extensible.

Features

• features provided by dashboard widgets could cover:
  • last edited pages/documents
  • inbox/messaging
  • server/instance statistics (heap space, processor load, device space left, amount of logged-in users etc.)
  • server/instance health & logs (repository state, recent error messages and warnings etc.)
  • help topics & tip-of-the-day
• user customizable: which widgets shall be displayed and where
• default dashboard configurations per role/group
• state-aware widgets
• simple widget API for allowing developers to create their own custom widgets

Post-it #2

Feature: Messaging (3)

"Messaging" should be renamed to something more general, maybe add non-displayed content or "meta-content"

More generally this feature could provide functionality to add data to a page that is not displayed on the page itself (like paragraphs do) but in terms of meta-data as it is for instance the case for "todo" items.

Applies to:

• marking pages with "todo"/"needs review" items
• adding comments to pages
• may also be used for "last edited page" feature

Related to:

• Feature Dashboard

Category: General / Editing

Feature: Actions (5)

Problem
In the current version of the Admin Central actions are used widely but are not realized as a well-defined concept. From usability as well as from technical perspectives there arise some problems which can be solved by applying the improvements described in the section below.

Solution/Features

• usability: define a single place where the user finds all the actions available for the current selection (i.e. in the "current context"). Currently, actions are sometimes only available through the context menu, sometimes only through the function bar. The user should not have to "guess" where to find which action, since this is neither efficient nor convenient. See [Feature: Function Bar]
• usability/technically: allow actions to be applied for multiple items at once as it is the case in most desktop applications. This feature is further described in the [Feature: Bulk Changes] section.
• usability: allow actions to be accessed through keyboard shortcuts. See [Feature: Keyboard Support]
• usability: allow displayed actions in function bar/context menu be customized on a per group/role/user basis
• technically: define a clear API for actions similar to the one for commands. This API should expose different aspects of the action which the UI needs to display and link the action correctly, specifically those are:
  • label of the action (i18n)
  • description to be used as tooltip (i18n)
  • keyboard shortcut (customizable)
  • action method (or delegate)
  • applicable subject types/conditions (rules)
  • flag to indicate if bulk execution is allowed
  • help link (i18n)

Post-it #3

Feature: Action Dialogs (5)

We need dialogs to be able to let the user specify parameters for actions.

Use cases:

• delete confirmation
• "superuser permissions required"
• activation comment
• for link checking: "remove all references"
• import/export: ZIP upload/download

TODO, Post-it #38

Feature: Bulk Changes (5)

TODO
see Interaction Bulk Changes

Post-it #5

Feature: Toolbar (5)

Previously named "Function Bar" - Vivian Steller

Detailed description can be found on the separate feature description page. 

Features (prioritized, descending):

• allow menus in toolbar e.g. for "New" button to directly specify the type of the newly created item
• support separators and place holder spaces
• customizable: which items shall be displayed, where and how (icon, text only)
  TODO

Drafts

 

Post-it #7

Feature: Context Menus (5)

TODO

Post-it #29

Feature: Property Bar (3)

Discussion:

• do we want the Property Bar (means a box which content changes upon selection change) at all?
• should it be editable? If not rename this feature to "Info Bar". If yes, directly or by explicitely hitting "edit"?
• where should it appear? On the left or on top?

Applies to:

• page meta-data (data that is not covered by page properties)
• document properties
• maybe also other configuration dialogs or security subjects

Conflicts with:

• dialog metaphor

TODO discuss feature

Drafts

Post-it #31

Feature: Masked Views/Advanced View Filters (2)

Scenario Authorization: configure security settings for a specific role

• administrator switches to mask "security"
• select role ACLs to be edited (subject)
• only those parts of the Admin Central, hierarchies etc. are shown that may be accessed by currently selected role (filter, rule)
• not accessible areas can be displayed but not highlighted (highlight flag, elements that don't pass the rules)
• the context menu/separate column contains the items: allow read, write, etc.; deny (decorate UI)

Applicable for:

• synchronization (filter for not activated content)
• subscriptions
• i18n (browse specific locale)
• authorization
• task-oriented working

TODO, Post-it #15

Category: General / Navigation

Feature: Breadcrumb Navigation (4)

Drafts

Why?

• preserves context information

Features:

• support ellipses ("...") for middle part

Remember:

• maybe consider synchronization with back-button/browser history

TODO, Post-it: #25

Feature: Location Bar (2)

Idea: allow putting in an address to directly jump to a node.

Features:

• auto-completion for nodes available on the current level

TODO

Design:

• combine with breadcrumb navigation

Related to:

• Feature Breadcrumb Navigation

Post-it #26

Category: General / Help

Feature: Help Page & Contextual Help (2)

Idea: in general, provide descriptive help texts and links to appropriate help topics in the UI.

TODO

Post-it #24

Feature: Tool Tips (2)

Related to:

• [Feature Contextual Help]

TODO

Post-it #30

Category: Content Management / Pages

Feature: Virtual Website Hierarchy (4)

Previously this features was called "Additional Website Hierarchy Responsibilities"

As a motivation for this feature refer to URIs and virtual URIs.

Drafts

This feature is covered in more detail on the separate virtual hierarchy feature page. 

Post-it #19

Category: Content Management / Content

Feature: Editing in Multiple Modes (4)

Currently we only support editing contents in the preview mode. However, since Magnolia should not only support web content management but content management in general. This means that in some scenarios pages or JSP templates are not available, thus the user can't edit content at all. In other cases the template might be more complex and using such a template for putting in data is difficult (e.g. when using AJAXed paragraphs).

To solve this we should introduce a generic, template independent view to manage contents, the list mode

TODO
DP: Tabs

Drafts

Post-it #27

Feature: Inline Editing (3)

TODO Discuss

Discussion:

• which sections should be editable in-place?
• also in preview mode?

Post-it #23

Feature: Creation of Items of another Workspace (4)

Previously named "Create Data Module Items with Inline-Editor"

Currently, in the preview editing mode one can't create contents defined by the data module. However, it would be very nice if contents for the following modules could be selectable directly in the "New Paragraph" dialog:

• poll: e.g. creating a poll does not require creating a page but a poll entry in the poll module workspace
• data: e.g. creating a product to display it on a product page automatically puts it into the data module
• dms: e.g. uploading a document to a page automatically puts it into the DMS
• eventually forum: create forum, thread

TODO, Post-it #22

Feature: Support for Editing I18ned Content (4)

Pros:

• maybe good marketing aspect
• could be a starter to define "best practice" for I18n

Cons:

• very hard to define since I18n can be done in several ways

TODO, Post-it #28

Drafts

Feature: Support Linked Paragraphs (4)

This feature is generally belongs to the topic: Content Re-use.

TODO, Post-It #35

Feature: Activation (5)

Currently activation is handled very simply. Especially errors on activation are not indicated clearly.

TODO review the concept of indicating the activation status of a node/page and provided more precise information if possible.

Post-It #36

Category: Administration

Feature: Configuration Dialogs (5)

TODO prioritize set of dialogs (maybe only the ones that already exist as menu items)

TODO
server
info/health
default URI (or website tree?)
default extension
MIMEMapping
defaultBaseURL
mail server
logs/logging
access
backup
automated backup/schedule
system i18n
default/role based UI preferences
menu
security
IP config
rendering
repositories
URI2Repository mapping
link to browser
content i18n
page templates
grouped by module
paragraphs
dialogs
subscribers/instances
cache
filters
import/export
previously also: development tools (as options)
workflows
scheduler

Drafts

 

Post-it #16

Feature: Tools Dialogs (5)

TODO specifiy exact list

• repository/query browser

Note:

• import/export should be better defined as Action Dialog (see Feature Action Dialog)

Post-it #18

Feature: User preferences (3)

TODO

Features:

• change password, user name, email address

Post-it #13

Category: Administration / Security

Feature: Hierarchical User Groups (2)

Idea: currently it is very hard to identify which group inherits ACLs from which parent group (especially if it inherits them recursively). This issue should be addressed by this feature.

Maybe this is not a new feature and will thus be covered by the general design of the security dialog(s).

TODO

Post-it #21

Category: Administration / Modules

Feature: Module Manager (5)

Features:

• lists currently installed modules with title, description, version
• provides module details: workspaces, dependencies etc. (basically everything configured in module descriptor)
• install, un-install, re-install and enable/disable module
• upload module (maybe container dependent)

Future:

• download module from remote repository

TODO

Note:

• technically requires module management mechanism, alternatilvely it could be just an info dialog

Post-it #11

Feature: Module Configuration Dialogs (3)

Idea: allow modules to provide dialogs to configure them.

TODO

Post-it #17

Category: Administration / Templating

Feature: Template, Paragraph and Dialog Relationship Improvements (5)

Problem

• configuration options for paragraphs neither spell nor type checked
• relationship is configured through configuration in repository and hard coded templates

Solution

• use a UI input mask (++)

Consequences
TODO

Post-it #8

Feature: Template/Paragraph permissions & logic (5)

Related to:

• Feature Template Paragraph Dialog Improvements

TODO
who can create pages/paragraphs where with what template?

Post-it #12

Feature: Separating Layout and Style (1)

Related to:

• Feature Template Paragraph Dialog Improvements

TODO

Post-it #9

Controls & Components

In the new GUI, we should support the following controls.

Common functionalities for all controls:

• control states
  • enabled/disabled
  • editable/read-only
  • hidden/visible

Action Sources
Common functionalities:

• keyboard shortcut support

List of controls:

• Button
• Link Button

(Editable) Value Holders
Common functionalities:

• validators
• formatters
• converters
• auto-completion/suggestion

 
 
Abstract/Wrapping controls:

• multi-value wrapper
• composite

  e.g. link: redirect/forward/internal + qualified name

  
  

List of controls:

• label
• single-line text
• password
• multi-line text
• rich text
• (fully) qualified name / path
  • (checked) reference/link

    alerts if referenced node doesn't exist anymore

  • type name (Java, JCR)
  • identifier (text, UUID)
• datetime/date selector
• select-boolean
• select-one
  • mutable select-one
• select-many
  • mutable select-many
• binary/file-upload
  • appearance/functionality depends on MIME type e.g. image/* or specific subtypes

Structural Components
Common functionalities:

• filtering
• mouse-wheel support
• partial loading/load in background
    !Features - Controls - Structural - Filtering.png|thumbnail!List of components:
• tree
• list
  • paging
• grid
  • customization
    • columns displayed
    • column ordering
    • column sorting
  • orderable columns
  • column sorting
  • modes (icons, details, etc.)
  • DP: Paging
  • DP: Pulldown Button
  • DP: Table Sorter
• grid tree

See the structural components detail page.
Navigational Components

• accordion

  fade-after-click effect
  highlight active/over

• context-menu
  • auto-size **
• address bar
• breadcrumb
  • updated on activation of an element

Layout Components

• flow
• grid
• tile
  • e.g. for documents
• card (tab)
  • DP: Tabs
• vertical-box
• horizontal-box
• (modal) dialog window

Informational Components

• progress bar
  • remaining time
  • percentage
• status information
  • indicate idle time (session timeout)
  • progress
  • messages (configurable display time)
• tool tip

Structure

See whiteboard

Navigational Structure

Screen Flow

Interaction

The following section covers important interaction scenarios which users perform when using Magnolia.

Note: the general navigation interaction is covered in the section Navigational Structure.

Managing Content

Creating Pages/Page Structure

• select location, see also Interaction Finding Data
• select page type
• select layout/template
• setup properties (type specific, general data, meta data, i18ned)
• save changes
• observe progress
• check result
  TODO

Creating Content

See detailed [interaction description page "Creating Content"]interaction description page "Creating Content".

Finding Pages/Content

advanced filtering, also see Feature Masked Views
different set of fields
two types: static filters (predefined) and dymanic filters (can be edited/saved)
quick search, see [\#Controls Structural Components]
one field only
suggestion
auto completion
sorting, grouping
also consider: changing view modes (hierarchy, preview), scrolling

TODO

Editing Pages/Page Structure

• select target page, see also Interaction Finding Data
• select/perform action
  • edit properties
  • copy, copy to...
  • move
  • delete
• observe progress
• save/apply changes
• check result
  TODO

Editing Content

• select target content, see also Interaction Finding Data
• select/perform action
  • edit data
  • convert type
  • copy, copy to...
  • move, move to...
  • delete
• observe progress
• save/apply changes
• check result
  TODO

Performing Bulk Changes on Pages/Content

User action sequence:

• select targets (either pages or contents, not both), see also Interaction Finding Data
• perform bulk change action
• confirm and save changes
• observe progress
• check result

TODO

Observing Progress of Action Execution

window appears
animation
see Controls Informational Components

TODO

Drafts

 

Content Life-cycle: Activating, Reviewing and Publishing Content

• see create page/create content/edit page/edit content (editor)
• select target, see also Interaction Finding Data
• trigger activation (add comment)
• observe progress
• check result
• perceive activation status change (manager when re-/activated, editor when rejected)
• review changes
• apply changes (publish, accept) or reject (add comment)
• observe progress
• check result
  TODO

Drafts/Illustrations

 

Exporting & Importing Data

TODO

we have to consider 3.6 changes before specifying this

Browsing Versions

Applies to:

• website pages/contents
• documents

Design:

• accessible via button in Feature Toolbar; either opens dialog to select old version/compare diffs or displays a drop down element to choose a version

TODO

Messaging (3)

Related to:

• Feature Messaging

TODO, Post-it #20

Managing Security

Drafts/Illustrations

 

 
 

Creating a Security Subject (User, Group, Role)

• select parent (realm/group)
  TODO

Assigning Permissions to Roles

• should be manageable through the website hierarchy

TODO 

Checking a Users Effective Access Restrictions

TODO

Refactoring an Existing Security Configuration

TODO

• extract roles from specific ACLs of other roles
• extract parent group of multiple child groups
  ...

Design