Lately we have seen an increase in projects that have failed to either get user friendly content integration or non satisfactory performance. Our intention is to mitigate any knowledge gap that our previous post might have left you with, therefore this post will repeat some recommendation or reference back to old useful post. Moreover this post will help you understand ground up how to design, architect and implement business enabled, responsive and performing portals with complex requirements on business centric information publishing.

Design the Information Model

The key to successful portal deployments is Information modeling, it's a key task to understand the use case you designing for, therefore I have designed a set of question you need to ask yourself or your customer:

Question: Who will own the content, IT or Business?
Answer: Business
Question: Who will publish the content, IT or Business?
Answer: Business
Question: Will there be multiple publishers?
Answer: Yes
Question: Are the publishers computer scientist?
Answer: No
Question: How often do the information changes, daily, weekly, monthly?
Answer: Daily, weekly

If your answers to the questions matches at least 2, we strongly recommend you design your content with following principles:

• Divide your pages in to logical sections, where each section is marked with its purpose
• Assign capabilities to each section, does it contain text, images, formatting and/or is it static and is populated through other contextual information
  
• Select editor/design element type
  WYSIWYG - Rich Text
  Plain Text - non-format text
  Image - Image object
  Static List - static list of formatted information
  Dynamic Data List - assembled information from multiple data files through CMIS query
  

The result of such design map could look like following below examples:

Based on the outcome of the required elements in the design column 3 from the left you will now simply design a data model in WebCenter Content - Site Studio by creating a Region Definition structure matching your design requirements.

For more information on how to create a Region definition see following post:
Region Definition Post - note see instruction 7 for details.

Each region definition can now be used to instantiate data files, a data file will hold the actual data for each element in the region definition. Another way you can see this is to compare the region definition as an extension to the metadata model in WebCenter Content for each data file item.

Design content templates

With a solid dependable information model we can now proceed to template creation and page design, in this phase focuses on how to place the content sections from the region definition on the page via a Content Presenter template. Remember by creating content presenter templates you will leverage the latest and most integrated technology WebCenter has to offer.
This phase is much easier since the you already have the information model and design wire-frames to base the logic on, however there is still few considerations to pay attention to:

• Base the template on ADF and make only necessary exceptions to markup when required

• Leverage ADF design components for Tabs, Accordions and other similar components, this way the design in the content published areas will comply with other design areas based on custom ADF taskflows
• There is no performance impact when using meta data or region definition based data

All data access regardless of type, metadata or xml data it can be accessed via the Content Presenter - Node. See below for applied examples on how to access data

• Access metadata property from Document - #{node.propertyMap['myProp'].value}
myProp in this example can be for instance (dDocName, dDocTitle, xComments or any other available metadata)
  
• Access element data from data file xml - #{node.propertyMap['[Region Definition Name]:[Element name]'].asTextHtml}
  Region Definition Name is the expect region definition that the current data file is instantiating
  Element name is the element value you like to grab from the data file

I recommend you read following  useful post on content template topic:
CMIS queries and template creation - note see instruction 9 for details
Static List template rendering

For more information on templates:
Single Item Content Template
Multi Item Content Template
Expression Language

Internationalization Considerations

When integrating content assets via content presenter you by now probably understand that the content item/data file is wired to the page, what is also pretty common at this stage is that the content item/data file only support one language since its not practical or business friendly to mix that into a complex structure. Therefore you will be left with a very common dilemma that you will have to either build a complete new portal for each locale, which is not an good option! However with little bit of information modeling and clear naming convention this can be addressed.

Basically you can simply make sure that all content item/data file are named with a predictable naming convention like "Content1_EN" for the English rendition and "Content1_ES" for the Spanish rendition. This way through simple none complex customizations you will be able to dynamically switch the actual content item/data file just before rendering. By following proposed approach above you not only enable a simple mechanism for internationalized content you also preserve the functionality in the content presenter to support business accessible run-time publishing of information on existing and new pages.

I recommend you read following useful post on Internationalization topics:
Internationalize with Content Presenter

Integrate with Review & Approval processes

Today the Review and approval functionality and configuration is based out of WebCenter Content - Criteria Workflows. Criteria Workflows uses the metadata of the checked in document to evaluate if the document is under any review/approval process. So for instance if a Criteria Workflow is configured to force any documents with Version = "2" or "higher" and Content Type is "Instructions", any matching content item version on check in will now enter the workflow before getting released for general access.
Few things to consider when configuring Criteria Workflows:

• Make sure to not trigger on version one for Content Items that are Data Files - if you trigger on version 1 you will not only approve an empty document you will also have a content presenter pointing to a none existing document - since the document will only be available after successful completion of the workflow
• Approval workflows sometimes requires more complex criteria, the recommendation if that is the case is that the meta data triggering such criteria is automatically populated, this can be achieved through many approaches including Content Profiles
  

Criteria workflows are configured and managed in WebCenter Content Administration Applets where you can configure one or more workflows.

When you configured Criteria workflows the Content Presenter will support the editors with the approval process directly inline in the "Contribution mode" of the portal. In addition to approve/reject and details of the task, the content presenter natively support the user to view the current and future version of the change he/she is approving.
See below for example:

Architectural recommendation

• To support review&approval processes - minimize the amount of data files per page
• Each CMIS query can consume significant time depending on the complexity of the query - minimize the amount of CMIS queries per page
• Use Content Presenter Templates based on ADF - this way you minimize the design considerations and optimize the usage of caching
• Implement the page in as few Data files as possible - simplifies publishing process, increases performance and simplifies release process
• Named data file (node) or list of named nodes when integrating to pages increases performance vs. querying for data
• Named data file (node) or list of named nodes when integrating to pages enables business centric page creation and publishing and reduces the need for IT department interaction

Summary

Just because one architectural decision solves a business problem it doesn't mean its the right one, when designing portals all architecture has to be in harmony and not impacting each other. For instance the most technical complex solution is not always the best since it will most likely defeat the business accessibility, performance or both, therefore the best approach is to first design for simplicity that even a non-technical user can operate, after that consider the performance impact and final look at the technology challenges these brings and workaround them first with out-of-the-box features, after that design and develop functions to complement the short comings.