1 Introduction to Developing with WebCenter Sites

In WebCenter Sites, both templates and information are stored as assets. So, you begin with designing an asset model; creating asset types and assets. You also design site layout, page templates, and pagelets. For security and performance, you develop caching framework and security model. There is more to keep you engaged until you turn in the site to someone who'll administer it therefrom.

1.1 About Developing with WebCenter Sites

Your role as a WebCenter Sites developer begins with building a core website, but it doesn't end here. You’ll also tailor WebCenter Sites interfaces as the need arises. Does your company plan to leverage marketing-oriented components of WebCenter Sites? Extending these features to marketers so they can collect visitor profile information and design promotions for those visitors may be one of your key areas.

Your tasks as a developer can be grouped as follows:

Building a website

To create a website, developers build the website's infrastructure, administrators create content management site and site navigations, and content contributors add content to the website.

This guide focuses on how developers can create a website's infrastructure using WebCenter Sites.

In WebCenter Sites, both templates and information are stored as assets. To develop infrastructure of a website, first an asset model is designed which incorporates creating asset types and assets. Once asset types are ready, site layout, page templates, and pagelets are coded, and caching is implemented for better performance. For website access, users, ACLs, and roles are created, as well as the users are assigned to the relevant roles. Various types of content is imported as assets. The infrastructure is then mirror published to the management system where administrator and content contributors start designing the site. See The WebCenter Sites Development Process.

Note:

Depending upon an organization's setup, either developers or administrators create a content management site (framework to contain the content of an online site) and site navigations. Content contributors add pages and contents to the site navigations, and approve the content so administrator can publish it to the delivery system where the site goes online and starts functioning like a website.

For detailed information about building a website, see Getting Started with Oracle WebCenter Sites, Building Your Data Model, Developing a Website, Developing Mobile Websites, Coding with Developer Tools, Managing Caching, Migrating Your Work to Your Content Management System, and Security: Managing Content Management Users.
Enhancing the website

Websites can be enhanced depending on the nature of the business and customer profile. Using WebCenter Sites, online sites can be designed such that they gather visitor information and personalize promotional messages for each visitor, capture data about website visitors and their usage of pages. Site pages can be integrated with Facebook, Twitter, Google, and so on, as well as gadgets and applications can also be designed and integrated with WebCenter Sites.

For detailed information, see Developing Personalized and Targeted Websites with Engage, Running A/B Testing, and Developing WebCenter Sites: Visitor Services.
Customizing WebCenter Sites

To make the development environment and experience efficient and the content contributor's job easier, you can customize the Oracle WebCenter Sites: Admin and Oracle WebCenter Sites: Contributor interfaces. You can alter properties, the dashboard, search views, asset forms, workflows, and so on for higher efficiency and productivity.

For detailed information, see Customizing Oracle WebCenter Sites.

1.2 Typical Tasks for WebCenter Sites Developers

Some of the tasks you accomplish to build your core website are designing your site’s data model, forms for users to enter information, sample assets, templates to display content assets, caching for performance.

See these topics for typical developer tasks:

1.2.1 Data Models for Content Display

WebCenter Sites developers build a data model for the content they need displayed on their website. WebCenter Sites supports the following data models:

Basic Asset Model: This supports a flat data structure, so basic assets cannot inherit each other's properties (called attributes in this guide). Content is entered by WebCenter Sites users and is stored as objects called assets in the WebCenter Sites database. Each type of asset is contained in one primary storage table in the database, such that basic assets of one type can be associated with basic assets of another type.
Flex Asset Model: This is a comprehensive data model in which each asset type uses several storage tables such that hierarchical data structures can be created, and child assets inherit attribute values from their parent assets. The flex asset model also supports flat data structures, within its own framework. Note that the flex asset model functions independently of the basic asset model; tables created within the two models do not intersect.

Whether you choose the flex asset model or the basic asset model depends on the complexity of the data you plan to serve to your visitors. The flex asset model has historically been used for creating large online catalogs of products. However, it can be used in less complex situations, and is especially desirable when the intent is to eventually convert flat data structures to hierarchical structures. The conversion process does not require you to re-create the data.

1.2.2 Content Entry Forms for Content Management Sites

WebCenter Sites developers use data models to create the content entry forms that contributors use to create content for the website. Each field in a content entry form maps to a corresponding column in a database table (or multiple tables). In addition, developers create the JSPs that render content entry forms in Web Mode and render published content on the website.

When content is ready for public delivery, it can be published to the website using either dynamic or static publishing. Formatted content is displayed on the website by JSPs. This table describes the difference between a dynamic WebCenter Sites page and typical HTML page.

Table 1-1 Static and Dynamic Pages

Static Page (HTML Page)	Dynamic Page (WebCenter Sites Page)
Single disk file, served by a web server.	Composed and created upon request.
One-to-one association between the HTML page and the page the visitor sees in the web browser.	The web page that the visitor sees can be composed of multiple components called pagelets, created from within WebCenter Sites.
No separation of presentation and content. As a result, it is difficult to modify presentation and content independently of each other.	Separation of presentation and content. As a result, presentation and content can be modified and maintained independently of each other.

1.2.3 Templates and Elements to Render Content on the Website

WebCenter Sites developers use APIs and JSP tags to code templates and elements used to render content on the website. The following programming components are used in the process of coding:

1.2.3.1 Element Files

In very simplistic terms, the main function of WebCenter Sites is to separate format from content. By separating the two, WebCenter Sites enables you to reuse the same bits of formatting code for many pieces of content. For example, to change the format of articles, you rewrite the code in one place, rather than having to rewrite code for every article in your system.

Your formatting code is stored in files called elements. The code extracts the content from the database and formats the content. Because content is formatted only when a page is requested, you have the opportunity to design pages that will be constructed on-the-fly, according to the identity of the visitor requesting them.

Element files are stored in the ElementCatalog table in the WebCenter Sites database. The names of your pages are stored in the SiteCatalog table. That is, the SiteCatalog table stores the entries for all the legal page names for your website. Each row in the SiteCatalog table is a page entry. Each page entry points to an element in the ElementCatalog table. The element being pointed to by a page entry is called the root element of the page entry.

WebCenter Sites renders your content into an online page by executing SiteCatalog page entries. Here is how it works:

A visitor enters a URL to your website in a browser.
The web server that processes the HTTP request maps that URL to a WebCenter Sites URL. For example, a WebCenter Sites URL would look like this:
```
http://www.FiscalNews.com/servlet/ContentServer?pagename=FiscalNews/Home
```
The text after a WebCenter Sites URL is called the pagename. In this example, the pagename is Fiscalnews/Home.
WebCenter Sites looks up the pagename in the SiteCatalog table, determines its root element, locates that element in the ElementCatalog table, and then invokes that element.

The element is executed. Elements that are called from within the root element are executed in turn.
The results (images, articles, and so on, including any HTML tags) are rendered into HTML code and returned to the visitor's browser.

The result is a page that is dynamically rendered on demand.

1.2.3.2 APIs and JSP Tags

WebCenter Sites includes several tag families that you use to code your elements. The tag families enable you to identify, extract, and then display assets on your website. WebCenter Sites also provides Java methods and utilities that you can use for designing your website, for developing your own content management applications, and for customizing the WebCenter Sites modules/products.

For information about coding pages that display assets that use the basic data model, see Coding Elements for Templates and CSElements. For information about WebCenter Sites tags, see the Oracle Fusion Middleware Tag Reference for Oracle WebCenter Sites Reference.

The WebCenter Sites operating system consists of several servlets that run on top of an application server. Each servlet is invoked when necessary to perform a discrete set of tasks. Each servlet has a corresponding Java API with Java methods and JSP tags that you use to invoke the functions.

This figure shows the main WebCenter Sites servlets:

Figure 1-1 Main WebCenter Sites Servlets

Description of "Figure 1-1 Main WebCenter Sites Servlets"

The main WebCenter Sites servlets are as follows:

ContentServer: Generates and serves pages dynamically. This servlet provides disk caching, session management, event management, searching, and personalization services.
CatalogManager: Provides most of the database management for the WebCenter Sites database, including revision tracking, security, resultset caching, and publishing services.
TreeManager: Manages the tree tables, which store hierarchical information about other tables in the WebCenter Sites database.
BlobServer: Locates and serves binary large objects (blobs). Blobs are not processed in any way. They are served as is, as they are stored.
DebugServer: Provides tools that help you debug your XML code.
CookieServer: Serves cookies for WebCenter Sites pages, whether those pages are delivered by the ContentServer servlet or by the Satellite Server application.
HelloCS: Displays version information about the WebCenter Sites software installed on your system.

In general, you do not have to know which servlet performs which service or task. You simply invoke the appropriate Java method or XML or JSP tag and let the WebCenter Sites core application determine which servlet to call. The exception to this rule is when you write code that references a servlet URL. That is, when you include a link to a blob or to another page on a WebCenter Sites page. Because the ContentServer servlet and the BlobServer servlet reside at different URLs, you must include the URL of the appropriate servlet in your <A HREF> tags.

For information about the coding links to blobs and pages, see Website Development with Tag Technologies and Coding Elements for Templates and CSElements.

1.2.3.3 Sessions and Cookies

WebCenter Sites automatically creates a session for a visitor when he or she visits your website for the first time. You can store information about that visitor in session variables by using the tags and methods in the WebCenter Sites core. Subsequent elements can then access those variables and respond conditionally to them.

Session variables, however, are volatile. They last only while the session lasts, that is, until one of the following events occurs:

The visitor closes his or her browser.
The session times out after a period of inactivity. You control session timeouts by setting the cs.timeout property (in the wcs_properties.json file) from the Property Management Tool in the Admin interface.
The application server is restarted (except in a cluster).
The session is disabled in some other way.

Cookies are used to store information in a more permanent manner. You can code your elements to write cookies that store information about your visitors to their browsers. Then, you can use the stored information to customize pages and display the appropriate version of a page to the appropriate visitor when he or she returns to your website.

See About Sessions and Cookies.

1.2.4 WebCenter Sites Systems for Development, Management, Delivery, and Testing

When you are working with WebCenter Sites for your content management needs, you and the others on your team work with up to four different systems:

Development System: Where developers and designers plan and create the website. All of the WebCenter Sites products that you have purchased are installed on this system.
Management System: Where content providers such as writers, editors, graphic artists, and marketers are assigned to content management sites to develop the content that is delivered to visitors of the website. Revision tracking and workflow features track changes to assets (content), monitoring them until they are approved to be published to the delivery system.

Content management sites represent the real website. For example, you could create separate content management sites for separate sections of your website because the teams who provide content for each section work completely separately from each other and only members of that team should have access to that section (content management site). Or, you could create a content management site that represents an entire website, as does the avisports sample site. See Assembling Content Management Sites in Oracle Fusion Middleware Administering Oracle WebCenter Sites.
Delivery System: Here the content you are making available or the products that you are selling are served to your visitors or customers.

To deliver content dynamically, you should install all of the WebCenter Sites products that you purchased on this system. To deliver content statically, that is, to serve static HTML pages, your delivery system needs a web server only. That is, you don't have to install any of the WebCenter Sites products on your system.
Testing System: Where you or your QA engineers test the performance of both the management system and the delivery system. Testing can be performed on either a dedicated system or on the development system itself.

WebCenter Sites developers spend the majority of their time working on the development system. When the asset types that you develop and the site that you have designed are ready, you migrate (publish) your work from the development system to the management system. As assets are created, modified, and approved by the content providers, they are published from the management system to the delivery system.

1.2.5 Approvals and Publishing

When you finish developing the website, you publish your work (templates, elements, asset types, the site navigation, and so on) from the development system to the management system. Publishing your work makes it available on the management system. Contributors can then use the asset types and your site design to create content for the website. When contributors are finished creating the site content, that content (along with the supporting asset types, templates, elements, site navigation, and so on) can be approved and published to the website.

When assets are ready to be published, someone first marks them as approved. Then, when the publishing process is ready to start, it invokes the approval system which compiles a list of all the approved assets and examines all the dependencies for those assets. Assets linked to an approved asset must also be approved before the asset can be published.

The WebCenter Sites publishing and approval systems track and verify all the asset dependencies to maintain the integrity of the content on your delivery system. The publishing and approval systems ensure that the assets that are ready for publishing are the only assets that get published.

When you publish content and elements, WebCenter Sites copies them from one system (for example, your management system) to another system (for example, the delivery system). WebCenter Sites delivers two publishing methods that are built from the WebCenter Sites publishing APIs. These publishing methods interact with the WebCenter Sites approval system, an underlying system that determines which assets have been approved.

The WebCenter Sites publishing methods are:

RealTime: The dynamic publishing method. It is built with the WebCenter Sites RealTime API to copy approved assets from the WebCenter Sites database on one system to the WebCenter Sites database on another system.
Export to Disk: The static publishing method. It renders your approved assets into static HTML files, using the template elements assigned to them. An administrator or automated process then copies those files to your delivery system using FTP or another file transfer method.

1.2.6 Caching to Optimize Performance

Developers implement various caching frameworks to optimize the performance. WebCenter Sites also supports the use of Satellite Server caching, which provides a second level of caching and can also be used as a remote cache for your web pages. By default, WebCenter Sites and Satellite Server use inCache as their page caching framework. The following topics describe caching:

1.2.6.1 Page Caching

Page caching is implemented at the template level and is used to cache pages on the WebCenter Sites system. Page caching plays a significant role in system performance. A cached page can be served much faster than it can if it must first be generated.

WebCenter Sites alone (independently of Satellite Server) can separately cache each page or pagelet that is identified by a page entry in the SiteCatalog table. You can mark the expiration date of any pagelet in the cache by specifying a value for that page entry in that table.

Page caching is made especially effective by the addition of Satellite Server. Installing a Satellite Server application amounts to installing page caches on the servers that host Satellite Server, thereby extending the WebCenter Sites page cache.

1.2.6.2 Resultset Caching

Resultset caching is another feature that can greatly enhance system performance. When the WebCenter Sites database is queried by any mechanism, the WebCenter Sites application can cache the resultset that it returns. It keeps track of every table in the database. Whenever a table is modified, it flushes all the resultsets that were cached for that table.

See Working with Resultset Caching and Queries.

1.2.6.3 Asset Caching

Asset caching is a memory-based system that is built on the inCache framework to optimize the performance of WebCenter Sites by taking up load that would otherwise affect the database. In WebCenter Sites, programmatic usage of assets consists of loading and rendering their attributes. Given that assets are loaded by templates, which are stored in the WebCenter Sites database, AssetCache is used only on WebCenter Sites nodes. Asset caching includes the AssetCache container component which functions by caching assets and interacting with existing inCache components.

See Using the inCache Framework in Oracle Fusion Middleware Administering Oracle WebCenter Sites.

1.2.6.4 Satellite Server Caching

Satellite Server is a caching application. It supplements WebCenter Sites caching functionality by providing additional page caches. The tandem use of the WebCenter Sites and Satellite Server caches results in automatic double-buffered caching.

By default, co-resident Satellite Server is installed on the same computer where WebCenter Sites is installed. You can further improve your system's performance by installing Satellite Server remotely so it can cache pages and pagelets closer to their intended audience. Remote Satellite Server hosts are fast, inexpensive caches of WebCenter Sites pages. They reduce the load on the WebCenter Sites host, dramatically increase the speed of page delivery to your site visitors, and provide a simple and inexpensive way to scale your WebCenter Sites system.

1.2.6.4.1 HTTP Requests

When the load balancer routes an HTTP request for a page to Satellite Server, Satellite Server either serves the page if the page is in its cache, or if the page is not cached, it forwards the HTTP request to WebCenter Sites. The basic chain of events is the following:

Satellite Server checks its cache.
What happens next depends on whether the page is in the Satellite Server cache (see Table 1-2 for details).

Table 1-2 Pages in or not in the Satellite Server Cache

Page in the Satellite Server Cache	Page Not in the Satellite Server Cache
Satellite Server serves the page to the visitor's browser. In this case, Satellite Server does not have to forward the request to the WebCenter Sites database, thus reducing the load on the database.	Satellite Server forwards the request to WebCenter Sites. WebCenter Sites returns the cached pages from its cache to Satellite Server. It renders the page which is not in its cache, caches a copy, and sends the page to Satellite Server. Satellite Server then caches the page and serves it to the visitor's browser. When requested again, the page is served from the Satellite Server cache, which reduces the load on the WebCenter Sites database.

Page in the Satellite Server Cache

Page Not in the Satellite Server Cache

Satellite Server serves the page to the visitor's browser.

In this case, Satellite Server does not have to forward the request to the WebCenter Sites database, thus reducing the load on the database.

Satellite Server forwards the request to WebCenter Sites.
WebCenter Sites returns the cached pages from its cache to Satellite Server. It renders the page which is not in its cache, caches a copy, and sends the page to Satellite Server.
Satellite Server then caches the page and serves it to the visitor's browser. When requested again, the page is served from the Satellite Server cache, which reduces the load on the WebCenter Sites database.

Each Satellite Server application is independent of every other Satellite Server application. An individual Satellite Server application has the following characteristics:

It maintains its own cache.
It cannot request pages or pagelets from another Satellite Server application. It can request pages or pagelets from only the WebCenter Sites core.

1.2.6.4.2 Satellite Server Servlets

Satellite Server is made up of several servlets: one that caches and serves pages, and two that manage the cache:

Satellite: Caches pages at the pagelet level. The Satellite XML or JSP tags in your elements indicate which pagelets should be cached, and they control various Satellite Server settings.
Inventory: Enables you to examine the Satellite Server cache so you can obtain the information you need to manually flush individual pages or pagelets from the cache when necessary.
FlushServer: Handles all types of cache-flushing. FlushServer can either flush the entire cache, or can flush individual items from the cache.

For information about coding pages with the Satellite Server tags and page caching in general, see Understanding Page Design and Caching.

1.3 WebCenter Sites Utilities

Many GUI-based WebCenter Sites utilities are available for you to manage the WebCenter Sites database and various code. Decide which utility you need and install it on your system.

Developer Tools, which integrates WebCenter Sites with the Eclipse Integrated Development Environment (IDE). The Developer Tools kit enables WebCenter Sites developers to work in a distributed environment using tools such as Eclipse and version control system (VCS) integration.
Sites Explorer, for viewing and editing tables in the WebCenter Sites database.
CatalogMover, for exporting and importing database tables.
XMLPost, for incrementally importing data into the WebCenter Sites database.
BulkLoader, for quickly importing large amounts of data into the WebCenter Sites database.
Property Management Tool, accessible from the Admin interface, for viewing and organizing the wcs_properties.json file (system configuration files).

1.4 WebCenter Sites Interfaces

You’ll use the Admin interface to accomplish several different tasks. However, it’s a good idea to get familiar with Contributor and WEM interfaces, too.

Admin Interface: The Admin interface allows developers and administrators to manage and configure WebCenter Sites.

Figure 1-2 Admin Interface

Description of "Figure 1-2 Admin Interface"

The tree panel on the left contains all the content management elements that developers and administrators have to work with. The workspace area on the right is where all the tasks and operations are performed.

The Admin interface supports code-based operations, and enables you to graphically complete the creation of basic asset types. For example, to create a basic asset type, you would:
1. Write an XML file (called asset descriptor files) to define the basic asset type.
2. Upload the file to WebCenter Sites.
3. Invoke the AssetMaker utility. One of the functions of the interface (AssetMaker) is to read the asset descriptor file and, from it, create a storage table for the asset type. Other functions in the interface allow you to configure the asset type (for example, name its authorized users).
The same interface is used by administrators to create content management sites, manage system users, control their permissions to content, establish workflow processes, and configure WebCenter Sites features (such as Mobility).
Contributor interface: The Contributor interface is designed specifically for content providers and business users. It provides ease of use and quick access to most WebCenter Sites content management functions, such as previewing, creating, editing, deleting, and approving assets.

Figure 1-3 Contributor Interface

Description of "Figure 1-3 Contributor Interface"

When you work with assets in the Contributor interface, you may see fields enabled with the following WYSIWYG editors:
- CKEditor: An open source WYSIWYG text editor from CKSource which requires no client-side installation. Developers can use CKEditor to create basic assets whose text-entry fields use CKEditor as the input mechanism for the field. Developers can also create attribute editors for flex attributes that use CKEditor as the input medium.
- Clarkii Online Image Editor (Clarkii OIE): A popular third-party image editor from InDis Baltic. Developers can enable Clarkii OIE to allow users to edit images directly in the Form Mode eliminating the need for an external image editor.
WEM Admin Interface: The WEM Admin interface is designed specifically for administrators to manage the assignment of applications and users to sites using roles.

Figure 1-4 WEM Admin Interface

Description of "Figure 1-4 WEM Admin Interface"

See Also:

Using the Web Experience Management Framework in Oracle Fusion Middleware Administering Oracle WebCenter Sites and Developing Applications with the Web Experience Management (WEM) Framework.

1.5 Use Case Scenarios for WebCenter Sites

WebCenter Sites provides capabilities for business-user content authoring, delivery of high-scale dynamic sites, content targeting and optimization, user-generated content, end-user personalization, marketing and lead generation, and mobile Web delivery. WebCenter Sites is used in a variety of industries to create informational and branding websites that run marketing campaigns and generate business leads.

These topics describe WebCenter Sites use cases:

1.5.1 Developing Informational (Branding) Websites

WebCenter Sites provides easy-to-use and efficient features to develop branding websites for products and services. The starting point is creating the basic infrastructure using the WebCenter Sites core. Consider the following when designing a website with WebCenter Sites:

Content Type: The first thing to determine is how the site content should be categorized and designed in WebCenter Sites. Which content type should be structured and which should be binary? Content that content contributors create in WebCenter Sites through Form or Web mode is structured, but imported content (such as Microsoft Word files) is binary.

Architects determine the following about content types:
- Which content types should have variable attributes and which should have fixed attributes? A product model or service type of content may require variable attributes as companies improve their existing range of offerings from time to time.
- Which content should be flat and which should be hierarchical? For instance, images are usually flat or basic type. A product accessory model such as headphones for a MP3 player can be hierarchical.
- Based on the product or service, which content should inherit attributes from other content? A product model may need to inherit attributes from the parent product. Some content types may be standalone.
- Some content types require associated content. For example, you may need to associate an article about a product model with articles about similar product models or the parent product.
- How will contents be recovered if a disaster occurs?
These considerations determine the asset model and its implementation. Typically, websites require a combination of basic and flex assets. For information about how content types are determined and designed in WebCenter Sites, see Understanding the Asset Types and Asset Models.
Content Volume: A website should be designed to handle any volume of content. It should be scalable.
Pages: A page contains many pagelets that can be reused. When designing pages consider reusability benefits as well as caching strategy for better performance. See Coding Elements for Templates and CSElements and Understanding Page Design and Caching.
Page Caching: For better performance, determine when pagelets will be used. Design page templates to use fewer uncached pagelets per page. See Managing Caching.
Templates: Before designing templates, consider those scenarios when template components might be reused; pagelets can be reused on other pages. Some examples of pagelets are: Top, LeftNav and Footer as they are likely to be reused on many pages. See Developing a Website.
Content Mode: WebCenter Sites lets you include Form mode and Web mode in your content management site. While Form mode is quick to use, Web mode enables infrequent users or users who perform a limited role to find, edit, and submit content directly from the rendered (Preview) version of an asset. Web mode also enables content contributors to compare two or more versions of a web page to determine which version is more effective. See Developing a Website.
Content Management (CM) Sites: A CM site is the source of content for the online site and can represent either an entire online site or one of its sections. Consider customers' needs and determine how CM and online sites should be designed: whether a single CM site and its single online site, or a single CM site and multiple online site, or multiple CM sites and multiple online sites. See Content Management Models in Oracle Fusion Middleware Administering Oracle WebCenter Sites.
Multilingual Requirements: Find out what customers are looking for. Mostly customers want the ability to create content in a master language, wire it up to other related content (which may or may not be in the master language), then either publish it and translate it later. Or, they prefer translating the content and other related bits and pieces first, and then publishing the whole as a single package. Determine if customers want certain country-specific rules to apply to the rendered content. See Configuring Sites for Multilingual Support.
User permissions: You use Access Control Lists (ACLs) to restrict user access to the WebCenter Sites database and the rendered pages served on your sites by WebCenter Sites. WebCenter Sites also provides user tags to log in and log out users, as well as to create an account or edit user profiles. Some of the common user permissions are: create, edit, delete, approve content, rights to access WEM, Admin, and Contributor interfaces. Consider what all types of permissions should be created for different roles. See Creating and Authorizing Users in Oracle Fusion Middleware Administering Oracle WebCenter Sites and Security: Managing Content Management Users.
Security: Before developers begin designing the online site or contemplating changes to the user interface on the management system, you must determine and implement your security protocols. The decisions you make about security configuration affect the way that you code and implement your online site. See Setting Up External Security in Oracle Fusion Middleware Administering Oracle WebCenter Sites.
Customization: Customer teams interact with the Contributor interface to edit and update websites. For their efficiency and convenience, you can customize the Contributor interface components such as the site tree, dashboard, asset forms, search views, and so on. See Customizing Oracle WebCenter Sites.

1.5.2 Creating Marketing-Oriented Websites

Oracle WebCenter Sites enables marketers and business users to easily create and manage contextually relevant website content aimed toward sales and customer loyalty. It provides components that let you develop personalized and targeted websites, as well as facilitate analysis of websites' effectiveness to sell products and create new customers.

Oracle WebCenter Sites: Engage lets you design online sites that gather information about your site visitors and customers. Marketing uses this information to personalize product placements and create promotional offerings for each visitor.

The Oracle WebCenter Sites: A/B Testing module provides a feature to compare two or more versions of a web page to determine the most effective version that can help converting a website visitor into a website customer through a sale. WebCenter Sites allows many methods to analyze effectiveness of a page version. Some of them are: visitor clicking a link, visiting a certain set of pages, remaining on the site for a certain length of time, adding an item to a shopping cart, and other actions, as well as the sale of a product. For information, see Developing for A/B Testing.

For detailed information, see Developing Personalized and Targeted Websites with Engage.

1.5.3 Creating Mobile Websites

The WebCenter Sites' mobility feature lets you easily extend your web presence to mobile devices and deliver multi-channel marketing and customer experience initiatives while saving significant time, money, and effort in managing mobile sites. Use the mobility feature to create, preview, and deliver websites to a variety of mobile devices such as phones and tablets. For information about developing mobile websites, see Developing Mobile Websites.