Monday, April 21, 2014

Responsive Design - Practical Tips for Web Center Developers

This article will quickly make you comfortable with Responsive Design principles (RDP) and how they apply to your Oracle Content Management system. I'll also show you some real world examples of the reasons for and impact of implementing the RDP


RDP is an approach to designing HTML applications that look well on a wide variety of screen sizes, platform and screen orientation - as opposed to Adaptive Design - where the user's browser is detected and she is bounced to a "Mobile" site, that in many times look awful on modern high resolution devices.

Let's look at the fundamentals of RDP and then touch on the principles of Information Architecture (IA) and User Experience Management and see how these concepts apply to Enterprise Applications as well as the public facing high traffic web sites - domain where this concept first became relevant.


Check out how site looks in its mobile version on my tablet (See screenshot below)

Many times users are forced to install non-stock browser to fake User Agent string and get these sites to serve their desktop version instead.

Now let's take a look at another site that offers a striking alternative - Jyske Bank from Denmark. Here's how the site looks on my wife's iPhone:

Now browsing from an Android phone it will look like this:

Gradually increasing the resolution, the site will transform as these other screenshots below show:

And here's how the site looks at my laptop with full HD screen:

A lot of things are at play here and more visual elements are added as the screen real estate get larger. 
On the opposite, Amazon's full site relies on just one thing when the screen size goes down - scrolling (See screenshot below)

What a difference compared to Jyske Bank's smooth user experience. 


Responsive Design is a flexible, fluid web design that suits the screen resolution and the  device in use. While modern smart phones and other mobile devices seem to be the most relevant application, supporting various screen resolutions across the enterprise is another strong case for using these principles. Not only this will provide a better fit on a smaller screen and eliminate excessive scrolling, it will also solve the inability of some gadgets to render heavy JavaScript-reliant content. 
Just a few years back majority of the sites were designed, reviewed and approved in Photoshop. Static images were developed for the major types of pages for a site and then they were cut into graphics and implemented in HTML. When mobile browsing started to become a noticeable trend, designers simply began to produce a second set of designs and that became their mobile sites. Now with  an ever growing array of devices and screen resolutions - this 'mobile vs. desktop' approach leaves too many users with less than optimal browsing experience. Desktop sites don't do well on most tablets, and most mobile sites don't look well on... pretty much anything.
Plus there's all that extra work required to maintain multiple versions of the site, so why not do one site that will work on every screen?


Lest look at the basic concepts at play at Responsive Design. Take a look at the following diagram


As Jeremy Keith said it, “Stop Thinking in Pages. Start Thinking in Systems.” 
Instead of beginning with your graphical elements and thinking of how to make them look ok in different browsers, start with the needs of each of these different browsers. The mobile browser, the tablet or the desktop browser becomes the different viewports of your design. 
You'll also  need to take into account connection speed and the scripting capabilities of your clients. For instance, you may need to serve a different set of graphics to a mobile client who may be running on a slower connection, then those you use for your desktop clients. And simply hiding your larger graphics with CSS will not make the site load any faster, so some server-side work may be required to support your design.


According to a Marketing Land, as of November 2013, 28 percent (and growing) of all web traffic coming from mobile devices. That percentage is even higher in US and many other countries. 
What that tells us is the smaller screens are the thing of the future  and designing your site so that it fits the mobile device's screen first makes sense. The site needs to look good and perform with a limited JavaScript capabilities and may also  take advantage of touch capabilities on mobile, where popular mouse over events will not work.
Taking this optimal mobile browsing experience as a baseline, you can progressively add new elements, such as additional content and graphics - without affecting the accessibility of a basic site. 
This is as opposed to the design-degrading approach which requires the toning down of heavy content to suit a mobile interface - an approach, that may often result in degradation of the content. 


Using the 'Mobile First' principle, a mobile interface becomes the starting point for your website. Additional features and content are then added as device capabilities increase.
This Progressive Enhancement formula presents a better alternative to the Graceful Degradation formula used in Adaptive Design. In the latter, one adjusts the complex features on a web interface, such as graphics, so that they can run on a mobile or a low resolution desktop client or slower network. As features are taken away, the appearance and functionality of the site get reduced, which results in sub-standard browsing experience.
This is why a progressive approach makes it perfect as it allows one to tweak content so that it is accessible on any device, without reducing its features. You upgrade it on a preferential basis, meaning only when the device supports that additional functionality.


Graceful Degradation Principle is an opposite to the Progressive Enhancement. It starts with your full blown desktop site and it uses media queries (please see below) to resize, reposition, hide or replace heavy graphic or JavaScript driven elements with lighter versions. 
Media Queries web site ( maintains an impressive array of RDP based sites but the site itself uses Adaptive patterns are graceful degradation. It simply resizes it’s graphics and repositions it’s header when the screen gets smaller - (See screenshot below) 

Unlike the Progressive Enhancement where you spend the time to make sure that even on the smallest screen, users receive full functionality and they get extras as they progress to a more capable devices, you are forced to take away features and functionality as you trying to degrade your design to allow it to run on smaller form factors. All of your thinking is then done on the desktop  part and your resulting mobile user experience may seem awkward and lack many important features. 


Break Points are the designer-specified thresholds in screen size where elements are added, replaced or rearranged. In the case of Jyske Bank product shelf splits into two at 1000 px, feature image disappears at 850 px, search box is replaced by a search button at 750 px, top menu is replaced by a menu button at 550px, left feature on the top disappears at 500px and the product shelf is replaced by product buttons at 450px
Break points can equally apply with both Progressive Enhancement and Graceful Degradation principles


Using pixels as opposed to percentages to size your objects may look great on your desktop monitor but it sure will not scale well on a smaller screen and cause an awful lot of scrolling. 
The same goes for using tables for laying out your page. Using  DIVs and positioning them with CSS  is a much better alternative. As screen gets smaller, your DIVs will automatically 'flow' into a single column and will continue to be accessible and may even look good without requiring too much effort on your end and no need to reduce or enlarge them.


Media Queries allow the page to adjust to the type of your output device (screen or printer) and its size. HTML4 and CSS2 currently support media-dependent style sheets tailored for different media types. For example, a document may hide it’s background image and use different fonts when printed. It may also switch to a lighter set of graphics when the screen size gets smaller.
Among the media features that can be used in media queries are ‘width’, ‘height’, and ‘color’. By using media queries, presentations can be tailored to a specific range of output devices without changing the content itself.
Here’s how your CSS might look:

@media screen and (max-width: 480px){ .header { background: url('img/bkg_small.jpg');} } 
@media screen and (min-width: 481px) and (max-width: 600px){ .header{ background: url('img/bkg_med.jpg');} } 
@media screen and (min-width: 601px){ .header{ background: url('img/bkg_lg.jpg');} }


Server-side plays an important role in many RDP implementations. Hiding Heavy JavaScript content and switching to a different set of graphics based on the type of device cannot be accomplished on just the client side alone.
Now it’s not easy to obtain the client's screen size on the server - without using Ajax or Flash - but simply setting a cookie on your start page (and updating it when screen size or orientation has changed) may be a simple enough alternative.
And now let's take a look at specific details of implementing the RDP in your WebCenter - driven apps:


There's no out of the box support for RDP yet but with a bit of creativity most principles can be implemented with minimum effort.


If you're using or planning to use WebCenter Sites - it comes with Mobility Server - a product that does it all for you - automatically formatting your site's content to fit the end user's device (See screenshot below)

Mobility Server offers in-context editing and preview of Sites for deployment to thousands of different mobile device types. You can set themes by device family and even access device's location to tailor your search results. Mobility also generates several different image sizes to optimize for different device types and for faster loading.


If you're still relying on Site Studio or you're integrating directly with Content Server - you can still take advantage of Digital Asset Manager (DAM) component and Video Manager Functionality. DAM will automatically generate various resolution sets for all types of images and have them ready for use in your design, so you'll only have to check in one high resolution image for each set. 
It will also convert your videos to streaming format and even generate thumbnails that you can also use on your site.


As I mentioned below, iDoc script makes it easy to set and retrieve cookies, so you can manipulate your page on the server side based on the 'screen size bracket' parameter that you set on the client. DAM is also a great tool to consider for generating your image renditions with various resolutions.


If you're developing the ADF - I recommend you checking out John Sim's article on developing fluid grids with ADF - he provides his own template here (
John suggest going with a custom HTML template because the ADF is driven by custom tags with each tag's output controlled by the renderkit - the HTML that you should not really modify.
The Content Server and the Site Studio do not pose any limitations on any kind of RD solution you will be working on. Just be sure not to use Design Mode in Site Studio Designer as it will mess up your code.


That's it for now. If you're new to RDP - you should now feel a lot more comfortable, have some insights and ideas of how to go about applying Responsive Design Principles with Oracle WebCenter... and if you're all for it, but your Management is still not entirely convinced, this article should've given you a few good reasons for them to seriously consider doing it. 

No comments:

Post a Comment