This post describes and contrasts responsive web design and portal page variants then offers best practice recommendations around them with respect to WebCenter portals.
Wikipedia describes responsive web design (RWD) as “an approach aimed at crafting sites to provide an optimal viewing and interaction 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).”
I’ll simplify that definition by saying it’s using CSS to make a page look good on all devices. If you’re unfamiliar with RWD, there’s lots of information about it across the Internet, here’s a good place to start. With respect to your WebCenter portal, here’s a couple of things you’ll need to know:
- You’ll need to make your page templates and page layouts responsive.
- As of 11.1.1.8, skins don’t support RWD (ie: media queries). That said, you’ll have to place your media queries in a separate CSS file and include it, along with any other RWD dependencies you may have, as an ADF resource is your page templates.
- Optionally, you may want to make some of your page components, things like custom content presenter templates, responsive as well.
Designed and implemented well, a responsive WebCenter portal can provide an interactive experience that rivals anything else on the net.
Unlike RWD, which is platform agnostic and used all over the net, portal page variants are implemented specifically for WebCenter portals. They work like this: each page within a portal can be assigned multiple views (i.e. variants), one for each supported device group. When an end user requests a page, the system checks to see if any variants exist. If there aren’t any then the default view (the only view available) is sent back. If variants do exist, then the device type of the requestor is checked against the page’s available variants. If there’s a match then that variant is sent. Should there not be a match then the portal falls back to some pre-defined default behavior, which is to either send the default page view or send nothing. To better illustrate how this works, consider the following example:
- The company intranet’s expense report page happens to have several page variants defined for it, one happens to be for iPhones.
- I use my iPhone 6 to access the expense report page. The page sent back presents me with a read-only history of my expense reporting activities: what’s been paid, what’s submitted and waiting for approval, and what’s unsubmitted.
- I get back to my desktop computer and go to the same page (i.e. same URL). The systems responds with a different page variant that shows more detail on this history, and also allows me to edit my active but unsubmitted reports.
Realize there can be a lot of overhead in managing portal page variants. First, you’ll need to define all the devices you want to support. This is done by specifying user agent strings and other device specific attributes for each device type. Next, you’ll have to categorize the devices you defined into device groups. Then lastly, you’ll have to create portal pages specific for each group. So, if you’ve created 5 device groups: desktops, iOS Phones, iOS tablets, Android phones and Android tablets, then you could maintain up to 5 variants for each page in your portal.
Given the two approaches, here are a few recommended best practices:
- DO use RWD as your primary mobile web strategy. RWD should serve as the scaffolding for your portal’s page templates and layouts. DON’T use page variants for this. It’s simply untenable.
- DO use page variants in conditions where you want the functionally and/or content on the page to be different based on the device the user is using.
- DO try to limit page variants to things you can build reasonable support policies around. Ex – The expense report page is supported on desktops, laptops and company issued iPhones only.
- DO try to keep your device types and groups as simple as possible. The preceding bullet point can help in achieving this one.
- DO realize that RWD and page variants are not an either/or situation. They solve two different problems and can co-exist quite nicely.
