Write for OTN
Earn money and promote your technical skills by writing a technical article for Oracle Technology Network.
Learn more
Stay Connected
OTN Architect Community
OTN ArchBeat Blog Facebook Twitter YouTube Podcast Icon

Building a Responsive WebCenter Portal Application

by JayJay Zheng Oracle ACE

Essential design and development considerations and how-to technical tips.

April 2014

Downloads
download-icon13-1Oracle WebCenter Portal
download-icon13-1Oracle ADF

Introduction

"Responsive web design is a web design approach aimed at crafting sites to provide an optimal viewing experience-easy reading and navigation with a minimum of resizing, panning, and scrolling-across a wide range of devices (from desktop computer monitors to mobile phones)." - Wikipedia

Despite the wide adoption and popularity of the concept of Responsive Web Design, there are no standards around it, and most progress has been made in the realm of traditional HTML development. WebCenter Portal is based on the Oracle Application Development Framework (ADF), whose user interface components (rich client components) are based on JavaServer Faces (JSF). Because they have their own user interface component library support, it is not the same as traditional HMTL development. Lack of best practices and successful stories of responsive Oracle WebCenter Portal development may feed into the perception that it is less popular or somewhat formidable. This article presents tangible information to serve as a guide to help you be successful with responsive design in Oracle WebCenter Portal.

In this article I will review the essentials of responsive web design, walk through how to design and develop a responsive WebCenter Portal application, and review the essential development considerations. The article covers technical aspects of building a responsive WebCenter Portal as well as the business decision points behind each scenario. It is intended for software architects, developers, and business users who regularly work with Oracle WebCenter Portal.

Thinking Ahead

Before diving into the design and development niche on responsive WebCenter Portal, let's review a few important "Thinking Points."

Think as One

The first thing to bear in mind for a responsive WebCenter Portal application is that there is always one application. While the portal might have different looks and feels across platforms, and might also transform into different shapes, it uses the same infrastructure, business model and technology stack to run the application. It requires the infrastructure, business model and technology stack to support all the mobile platforms you are planning to use. If any of the core technology with which WebCenter Portal integrates is not well supported on mobile platforms, it could impede the implementation, meaning that you may have to deal with the integration on the unsupported platform in a different way.

For example, consider the case where a WebCenter Portal application is an intranet portal and needs to integrate with Oracle Access Manager (OAM) for credential authentication. OAM further integrates with VPN security software provided by a third-party vendor. The VPN connection is required for users to login to the intranet portal remotely when they are not in the office. If the VPN software integration with OAM is not yet supported on a mobile platform, you would find it difficult or even temporarily impossible to implement the responsive WebCenter Portal intranet because of the lack of support on this one core component.

Think Mobile First

The concept of "mobile first" is worthy of an entire article of its own. The key tenet of mobile first thinking is that responsive design attends first to the most restrictive rendering device, which is a mobile platform. A mobile platform has many restrictions compared to desktop rendering, including:

  • Network bandwidth on a mobile platform is less optimal, so it's best to deliver less dynamic or complex data on a mobile platform, especially for the initial loading page.
  • A mobile platform has a smaller view port, meaning less data and information can be displayed, so you should deliver only the most important information to your audience.

Such restrictions should be weighed by the business and evaluated to make important decisions. Such "restrictions/disadvantages" of the mobile platform could be converted to "advantages." For example, the more focused area of a mobile platform can strengthen your core information.

Think Consistency

Consistency—in user interface, data and functionality—is the third tenet of responsive design.

Enforcing consistency strengthens brand unity and improves public perception of the business.

WebCenter Portal is a transactional platform that can integrate with web services, databases, content servers, Business Process Execution Language (BPEL) and many other business processes. Functional consistency can be built into such a transactional and responsive portal application. Imagine you start to process a series of workflow approvals on your desktop around 4:00 in the afternoon, and you still have a few to process after work. How nice would it be to have your tablet or mobile device ready at home to pick up what you left at work? Such functionality and transactional consistency will increase process efficiency and promote the brand.

Clearly, business scenario decisions and responsive design decisions should be made together. What are you hoping to achieve from the responsiveness?

Design Responsive WebCenter Portal

Every project, big or small, goes through the 4D process: discovery, design, develop and deploy. The same applies when building a responsive WebCenter Portal. I would like to focus on the design and develop stages, as the discovery and deploy stages are less technically relevant to this topic and vary from business to business. Let's look at what needs to be done to design a responsive WebCenter Portal.

Determine Layout Patterns

First of all, you need to determine the layout patterns. Layout represents the structure of the portal site and transforms its shape on different devices.

In an article on multi-device layout patterns, Luke Wroblewski establishes such multi-device layout patterns, with illustrated examples. The wider the screen size, the more layout options are available. With mobile phones, for example, there are few options; in the most common, all major components are vertically stacked. Obviously, for mobile, only the most valuable information should be displayed. As the size of the rendering device increases, more layout options are available, but it's important to maintain a consistent look and feel in the transformation of the portal from mobile to tablet to desktop.

Determine Navigation Patterns

Third, it is necessary to determine the screen or resolution cutoff points (or breakpoints), based on two criteria: For a solid review of best practices, see Brad Frost's work, here; it provides examples and technical analysis.

Determine Breakpoints

Third, it is necessary to determine the screen or resolution cutoff points (or breakpoints), based on two criteria:

  1. How many rendering devices need to be supported?
  2. What is the width range for each supported device?

Deciding which rendering devices must be supported is purely a business decision. Once that's determined, it will be easy to plot out the supported screen-size ranges. A handy list of displays by pixel density for many devices on the market is available on Wikipedia. guide to the display size by pixels for the majority of the rendering devices on the market: .

Having determined the layout pattern, navigation pattern, and breakpoints, you have accomplished the design portion of your responsive WebCenter Portal and are ready to develop it.

Develop a Responsive WebCenter Portal

Responsive web design is a client-side strategy that depends on CSS Media Query to carry out the client-side responsiveness. Introduced in CSS 3.0, CSS Media Query is a module that allows the defining of styles based on such conditions as screen size or resolution. A media query consists of a media type and at least one expression that limits the style sheets' scope by using media features like width, height, and color. You define the viewports with media queries (type, size, or other attributes), and then develop CSS styles to render the content in these viewports. The browser will evaluate the media queries and use the style definitions from the matching viewport when rendering the components.

Here is an example of a set of media queries defined by size (min-width and max-width) to set the browser breakpoints:

@media screen and (min-width: 320px) and (max-width: 479px) {
//define CSS for Mobile Portrait
}

@media only screen and (min-width: 480px) and (max-width: 767px) {
//define CSS for Mobile Landscape
} 

@media only screen and (min-width: 768px) and (max-width: 959px) {
//define CSS for Tablet Portrait
} 

@media only screen and (min-width: 960px) {
//define CSS for Tablet Landscape or Desktop
}
Note: Above, I've defined five media queries, along with the breakpoint ranges for each one; the device types mentioned are not necessarily appropriate for your business requirement. The media queries should be exclusive to each other and only one will be applied, depending on the size of the rendering device. In the media query, the developer defines the CSS styling that is in a specific range for the screen sizes. As a companion to the media query, a set of style classes determine whether a particular component should be displayed within a certain viewport range. Such a set of style classes is called a "responsive support class." I will use the media query sample above as a foundation to illustrate the responsive support class:
  • Larger than 320px but less than 479px: Mobile Portrait media query
  • Larger than 480px but less than 767px: Mobile Landscape media query
  • Larger than 768px but less than 959px: Tablet Portrait media query
  • Larger than 960px: Tablet Landscape or Desktop media query

The media queries are mutually exclusive, meaning that only one will be applied, depending on the size of the rendering device. In the media query, the developer defines the CSS styling that is in a specific range for the screen sizes.

The media query is to include a set of special style classes called "responsive support classes," which determine whether a particular component (including layout components) will be displayed within the breakpoint ranges. I will take the media query sample above as a foundation to determine the breakpoints, illustrating the responsive support class below:

Module Class Suffix Mobile(P)
480px and below
Mobile(L)
767px and below
Tablet(P)
959px and below
Tablet(L)/Desktop
960px and above
.visible-m-p Visible Hidden Hidden Hidden
.visible-m-l Hidden Visible Hidden Hidden
.visible-m Visible Visible Hidden Hidden
.visible-t-p Hidden Hidden Visible Hidden
.visible-t-l Hidden Hidden Hidden Visible
.visible-t Hidden Hidden Visible Visible
.visible-d Hidden Hidden Hidden Visible
.hidden-m-p Hidden Visible Visible Visible
.hidden-m-l Visible Hidden Visible Visible
.hidden-m Hidden Hidden Visible Visible
.hidden-t-p Visible Visible Hidden Visible
.hidden-t-l Visible Visible Visible Hidden
.hidden-t Visible Visible Hidden Hidden
.hidden-d Visible Visible Visible Hidden

visible-m-p: visible support class for mobile portrait
hidden-t-l: hidden support class for tablet landscape
visible-d: visible support class for desktop

The above example defines 14 support classes for 4 sets of breakpoints, 7 for visible support classes and 7 for hidden support classes. Among the 14 support classes, there are 4 duplicates (greyed out).

  • "visible-d" is a duplicate of "visible-t-l"
  • "hidden-m" is a duplicate of "visible-t"
  • "hidden-t" is a duplicate of "visible-m"
  • "hidden-d" is a duplicate of "hidden-t-l"

With the 10 applicable support classes, it's rare to use all of them in the real world. However, each one of the 10 support classes could possibly represent a valid use case. As per your own requirement, you can choose the ones that you would need to meet your requirements.

After determining the support classes and the set of breakpoints, we must bring them together. To toggle between the visible and hidden styling, we can use display:block and display:none, respectively. I will take all 10 applicable support classes and demonstrate how to embed them into a corresponding media query.

/*For Desktop or Tablet Landscape*/
@media all and (min-width:960px) {
.visible-m-p{display:none;}
.visible-m-l{display:none;}
.visible-m{display:none;}
.visible-t-p{display:none;}
.visible-t-l{display:block;}
.visible-t{display:block;}
.hidden-m-p{display:block;}
.hidden-m-l{display:block;}
.hidden-t-p{display:block;}
.hidden-t-l{display:none;}
}

/*For Tablet Portrait*/
@media all and (max-width:959px) and (min-width:768px) { 
.visible-m-p{display:none;}
.visible-m-l{display:none;}
.visible-m{display:none;}
.visible-t-p{display:block;}
.visible-t-l{display:none;}
.visible-t{display:block;}
.hidden-m-p{display:block;}
.hidden-m-l{display:block;}
.hidden-t-p{display:none;}
.hidden-t-l{display:block;}
}

/*For Mobile Landscape*/
@media all and (max-width:767px) {
.visible-m-p{display:none;}
.visible-m-l{display:block;}
.visible-m{display:block;}
.visible-t-p{display:none;}
.visible-t-l{display:none;}
.visible-t{display:none;}
.hidden-m-p{display:block;}
.hidden-m-l{display:none;}
.hidden-t-p{display:block;}
.hidden-t-l{display:block;}
}

/*For Mobile Portrait*/
@media all and (max-width:479px) {
.visible-m-p{display:block;}
.visible-m-l{display:none;}
.visible-m{display:block;}
.visible-t-p{display:none;}
.visible-t-l{display:none;}
.visible-t{display:none;}
.hidden-m-p{display:none;}
.hidden-m-l{display:block;}
.hidden-t-p{display:block;}
.hidden-t-l{display:block;}
}

Here is an example of consuming the defined responsive support class in a particular page. The responsive class is defined on the styleClass property of an ADF component.

<af:panelGroupLayout id="pg13" layout="vertical" styleClass="right visible-t" valign="top">

In a quickly expanding technology market, you may find new sets of rendering devices, with new screen sizes, becoming popular. The good news is that these new devices could be already covered in your media query; alternatively, you may need to slightly adjust the viewport size to adopt the new device screen size.

Responsive WebCenter Portal Considerations

There are a number of things to consider during the design and development of a responsive site in WebCenter Portal.

A Separate CSS File for Media Query

A WebCenter Portal skin CSS file has its own registration file and framework reference. ADF Faces components are based on Apache Trinidad; the skin CSS file is defined in an xml file named trinidad-config.xml. Such registered skins cannot recognize the CSS 3.0 syntax yet, so media query "@media" syntax will not be effective. To overcome this situation, you must create a separate CSS file for the media query usage and consume it from the page or page template directly, via ADF Faces component tag <af:resource>. For example:

<af:resource type="css" source="/CSS/responsive.css"/>

Apply Adaptive Page Templates

Responsive web design is a client-side response; server-side responsiveness is referred to as "adaptive design." The goal of achieving responsiveness is the same. Not only are responsive and adaptive not exclusive to each other, a hybrid of responsive and adaptive could be a preferred approach for WebCenter Portal applications. By leveraging the server-side adaptive approach, you can apply different page templates for different sets of rendering devices. This gives you the flexibility to apply specific navigations, layouts and other components to a particular device. It would be greatly beneficial to the performance and code maintenance. You can also use EL expressions to apply specific settings to device-specific components.

To detect the device type, use the Apache Trinidad RequestContext object and get the agent object:

RequestContext  context = RequestContext.getCurrentInstance();
Agent agent = context.getAgent();

From the agent object, you can get the device type and platform information. This way a different template can be applied to devices using EL expressions. However, this induces a limitation on the code maintenance to keep up the new supported devices. To overcome the challenge, you will still need to rely on the adaptive approach by the viewport size. Below is an example on how to achieve the adaptive page template on various viewport sizes.

First, let's have an "index.html" page as the portal entry. It will get the viewport width and redirect to the home page with a query string parameter to indicate the device type-desktop, tablet or mobile.

zheng-responsive-portal-app-fig01
Figure 1

The page template used for the home page is via an EL expression that points to a managed bean variable and is evaluated at server side.

<af:pageTemplate id="ptl" viewID="#{AdaptiveBean.pageTemplate}">

The managed bean gets the template from a session scope variable. If the variable is a null value (meaning that it's the initial page being requested), it will retrieve the value from the request query string and store it in session for subsequent use during the same session.

zheng-responsive-portal-app-fig02
Figure 2

Note that in the same session, the page template is determined at the portal entry point and is persistent throughout the session. During the same session, viewport size change will not trigger the page template switch, so resizing the browser window on a desktop will not induce the template change.

If you have WebCenter Portal implemented without responsive web design, the adaptive page template gives you flexibility to start your responsive web design without hurting your existing desktop portal, as you can now work on different templates for various viewport sizes.

Increase Component Reusability

Even if you're not incorporating responsive web design, reusability is desirable and should be considered in the early design phase of the WebCenter Portal application. With responsive web design, it becomes an even more important factor to consider. The reason is simple. Imagine you have a component of functionality or a portlet to be displayed on all your target devices: mobile phones, tablets and desktops. Do you want to develop separately for each device?

Reusability not only reduces development time, but also promotes future site maintenance and simplifies content updates. Updates in the reusable component are pushed to all rendering devices. Here are two areas that can be considered for achieving reusability.

  • Build reusable ADF task flows

    Task flows should be defined at an appropriate granularity to promote reusability. The same portion of content or functionality could be common across all devices, and thus wrapping it into a task flow could be a best practice. Expression language (EL) expressions can be applied on task flow as well as other components to differentiate the application of devices.
  • Build ADF declarative components

    Where it is not proper to put logic into a task flow, a declarative component-a reusable and composite component that comprises other ADF Faces components-might be a good choice. As with an ADF task flow, to achieve reusability the developer needs to develop it only once and reference it in multiple places.

Make Good Use of Stretchable Components

There are quite a few stretchable layout components in ADF, which can be stretchable to expand to the full width of the allowed viewport. The stretchable layouts are thus responsive components. Making good use of these stretchable components can make life a lot easier for a responsive WebCenter Portal-less code, less styling, and less maintenance.

Take a look at the ADF Faces Rich Client Demo site. Here is how it looks on a full-sized browser:

zheng-responsive-portal-app-fig03
Figure 3

When you reduce the browser view port size, the site looks like this:

zheng-responsive-portal-app-fig04
Figure 4

Such responsiveness takes advantage of using ADF stretchable components. By ADF geometry management, a typical layout component is stretchable only if it itself is a stretchable component and if its parent can stretch its children. The following table lists the ADF layout component and their stretchable properties.

LAYOUT NAME STRETCHABLE BY PARENT STRETCHES ITS CHILDREN
panelStretchLayout Yes Yes
panelGroupLayout Yes (if layout is scroll/vertical) No
panelBorderLayout No No
panelFormLayout No No
panelGridLayout Yes Yes
panelAccordion Yes Yes
panelSplitter Yes Yes
panelTabbed Yes Yes
panelDashboard Yes Yes
panelBox Yes Yes (only if being stretched by parent)
decorativeBox Yes Yes
panelCollection Yes Yes
panelHeader Yes Yes (only if being stretched by parent)
panelDrawer Yes Yes
panelSpringboard Yes Yes

Note that it's not enough to just have a stretchable container-the content inside the container needs to behave responsively as well. There are cases in which the components cannot be stretched. You will need to apply CSS styling with media query to achieve responsiveness for non-stretchable components or for those not stretched by their parent.

Let's take an example of rearranging the content inside a stretchable component to achieve responsiveness. In the image below, you'll see a portion of a page with the same content rendered in both iPhone portrait and landscape orientation. It contains three elements: a container named "WebCenter Portal"; an image; and a paragraph of text (with a link below it) inside the container. In both layouts, the container is stretched to take the full width of the rendering device. When we design the container as a layout component that is being stretched, all we have left to do is to rearrange the image from left to top of the text. The stretching of the container is automatically achieved by the ADF layout component itself. To rearrange the image, we can define styling like it is defined below, and assign "wcpimage" to the image component's style class.

/*For phone landscape*/
@media all and (max-width:767px) {
	af|Image.wcpimage{float:left;}
}

The portrait and landscape look like this:

zheng-responsive-portal-app-fig05
Figure 5

HMTL Code: Yes Or No?

Responsive styling in HMTL markup could be easier. This statement is generally true, and ADF skinning only increases the level of complexity within responsive web design. However, since it's a WebCenter Portal application, the ADF skinning cannot be avoided. In general, you shouldn't mix ADF Faces components with HTML in JSF pages because:

  • Styling becomes even more difficult when mixing HTML and JSF. JSF components are parsed into HTML markups at runtime. The styling applied using conventional HTML CSS will most likely override a lot of ADF skinning and produce unexpected behaviors.
  • The page development can be error-prone and induce performance issues. Embedding HTML markups inside ADF components could cause both compiling and runtime errors. ADF components use JavaScript from framework to support the final rendering of client components. Mixing with HTML could cause unexpected behaviors and impact performance.
  • The page code becomes messy and hard to maintain. In semantics, ADF rich client components do not expect HMTL markups as children or siblings. Mixing them violates the standards and causes inconvenience for those who need to understand or maintain the code.

The above statements are true, conceptually, but there are exceptions. Requirements on certain components might have to be developed in HTML, or it could be so much easier to develop a user interface element in HTML. If you cannot avoid HTML, proceed with caution or check with a seasoned ADF developer.

Build Responsive Content Presenter Template

This applies only to WebCenter Content Presenter usage. Content Presenter is a way to view, edit and create wiki documents, HTML files, or site studio files in the connected content repository. Content Presenter task flow defines what content, from where, to present. Content Presenter template controls how the content is displayed on the user interface. Earlier, we discussed that the content within a component needs to behave responsively in a responsive environment. Content Presenter Template defines responsiveness for content presenting. You should apply responsive design to ensure that this component plays along with the rest of the page in a responsive environment.

The Oracle WebCenter Portal Developer's Guide has documented this feature in more detail here.

Comply with ADF Faces Layout Design Basics

It's essential to comply with ADF Faces layout design basics. I have seen many cases of violating ADF user interface development, even from seasoned development teams. Compliance with the basic rules is strongly recommended for all WebCenter Portal application development-and you will find it even more important in responsive development. Violations of the basic rules can cost more time to troubleshoot, rework styling, and resolve inconsistent cross-browser issues. The ADF Faces layout design basics can be found here.

Summary

Responsive web design is not a technology, but a design and implementation strategy. With the wide and expanding use of mobile devices nowadays, it is necessary to consider a responsive strategy in your roadmap. Even if you have already developed your WebCenter Portal application without responsive web design in mind, you can still implement responsive web design on top of it with the help of the adaptive page template approach.

Responsive is the future of web design. The success stories of responsive sites on HTML have are loud and clear, but not in the world of WebCenter Portal. Before starting responsive web design on WebCenter Portal, it is very important to learn WebCenter Portal's features, respect its traits and follow best practices, as they are the basis of a successful responsive WebCenter Portal.

About the Author

JayJay Zheng, Oracle ACE and Director at Primitive Logic, has been working in the consulting industry with a focus on Oracle WebCenter, ADF, SOA and other Fusion Middleware stacks. He is a frequent session speaker at various conferences and maintains a technical blog at Anything about Fusion Middleware. Twitter Blog LinkedIn