Implement responsive web design using WebSphere Portal, Part 3: Developing multi-channel portlets

Working with common yet complex portlet user interfaces

Responsive Web Design (RWD) ensures a seamless user experience across multiple device types and form factors. For a truly adaptive and holistic site experience across devices, a responsive portlet user interface is essential. In this article, we discuss some of the more common yet complex portlet UIs and show how to use WebSphere Portal V8.0.0.1 to make them render seamlessly across devices, without having to maintain multiple code bases for each device type.

Share:

Jaspreet Singh (jaspsing@in.ibm.com), Software Architect, IBM

author photoJaspreet Singh is a software architect for the Rational WebSphere Portal tools in ICS. His areas of expertise span the WebSphere Portal domain, Eclipse plug-ins, Java Enterprise Edition (JEE), and Web 2.0 frameworks. He has presented at the Rational Software Development Conference in 2008, Portal Excellence Conference 2009, the Rational software Innovate 2010 conference, and the Exceptional Web Experience Conference in 2011.



Jonathan Lidaka, WebSphere Portal Front-end Engineer, IBM

Author photo - Jonathan LidakaJon Lidaka is a Front-end engineer at IBM's Research Triangle Park Development Lab. While in Portal development, he has primarily contributed to theme development, with a focus on accessibility and globalization, and to various components including the administration portlets and web application integrator. Jon has spoken at multiple IBM conferences on user interface design and optimizing a Portal theme for mobile devices. His current focus is on leading the mobile development mission for WebSphere Portal.



07 January 2014

Introduction

This series shows how to develop a responsive user interface using IBM WebSphere® Portal. Responsive design helps you get the most out of your web design effort, because the user interface is automatically optimized for screen resolution, orientation, and other capabilities of the display device. Gracefully adapting to these device attributes using elastic elements ensures that your site is usable and ready for future screen sizes.

Jammed-up back-end backlog?

Sign up for a free Bluemix cloud trial and fork this sample code to quickly add authentication, push notifications, and persistent mobile data to your app.

Now you can focus on the part of the app your parents actually understand. Learn more.

IBM WebSphere Portal has embraced responsive web design (RWD), and V8.0.0.1 has a default theme that is responsive, out of the box. This article examines the RWD aspects of portlet development, which can take a variety of forms and is very dynamic. To illustrate, we will create our portlets in IBM Rational Application Developer V8.5.1 and deploy them on IBM WebSphere Portal V8.0.0.1. To simulate a mobile device view, we will use a built-in RAD tool, the Mobile Browser Simulator (MBS).


Responsive design for portlets

To create a portal site that is responsive, the portlets and everything else on the portal page, including the portal skin and themes, must be individually responsive and adaptable.

Why do portlets need to be responsive? Since WebSphere Portal V8.0.0.1 has a default theme that is responsive, out of the box, why isn’t that sufficient? Your portlets also need to be responsive because every portlet will have a UI of its own. Depending on UI complexity, the portlet may or may not adapt itself to changing screen sizes. As a portlet developer, you will need to ensure that the portlets are optimized across devices.

This article will explain how to also make your portlets responsive so that the entire experience is consistently responsive. To understand portal theme development, see Part 1 in this series: "Implement responsive web design using WebSphere Portal, Part 1: Get started with the default theme."

CSS media queries

Examples in this article will rely heavily on CSS media queries. See Part 1 in this series to brush up on the basics.

A key aspect of CSS media queries is the break points that specify screen size boundaries. When implementing your responsive design, the content should dictate the break point values that you choose. Knowing the devices you want to target before the design process starts will ensure a more cohesive look and feel. Our examples will cater to the following screen sizes and devices, as shown in Listing 1:

  • Typical desktops and laptops: Larger than 800 pixels
  • Typical tablets: Less than 800 pixels
  • Typical smartphones (landscape mode): Less than 480 pixels
  • Typical smartphones (portrait mode): Less than 320 pixels
Listing 1. CSS media queries for default styles
/* Default styles for screen sizes > 800px */

/* Styles for screen sizes less than 800px, like tablets */
@media screen and (max-width: 800px) {

}

/* Styles for screen sizes less than 480px, like landscape mode in smartphones */
@media screen and (max-width: 480px) {

}

/* Styles for screen sizes less than 320px, like portrait mode in smartphones */
@media screen and (max-width: 320px) {

}

 

CSS styles for portlets

The recommended way to include portlet static resources like styles (CSS), JavaScript, etc. is to use a module that is included by the portal theme. Learn more about the portal theme optimization framework in Understanding the Portal 8.0 modularized theme.

Text size

Like any web application, portlets can have a variety of UIs. Depending on its business purpose, a portlet can have static content like text and images, or it can have dynamic and complex data representation using data tables, user input forms, etc. Adapting text and images is easier than adapting tables or forms to responsive design. Let's look at some of the more challenging UI components, starting with text size, and see how we can make them responsive.

For most websites, the predominant element is text, and it must adapt to changing screen size. As screen size decreases, a larger text size and additional padding around the text may be needed to increase usability for touch events on a mobile device. By modifying the “font-size” style attribute across the breakpoints, the text will be sized appropriately for mobile devices, as shown in Listing 2.

Listing 2. font-size style attributes
/* Default styles for screen sizes > 800px */

/* Styles for screen sizes less than 800px, like tablets */
@media screen and (max-width: 800px) {
	.samplePortlet{
		font-size: 1.2em;
	}
}
/* Styles for screen sizes less than 480px, like landscape mode in smartphones */
@media screen and (max-width: 480px) {
	.samplePortlet{
		font-size: 1.6em;
	}
}
/* Styles for screen sizes less than 320px, like portrait mode in smartphones */
@media screen and (max-width: 320px) {
	.samplePortlet{	
		font-size: 1.8em;
	}
}

The class samplePortlet scopes the styles to the portlet elements only.

For every change in device size, the font size is increased by a factor of the parent element, as indicated by use of em as opposed to static pixels. Using em allows for a relative size increase. However, the problem with using em is that the font size compounds, since it's relative to the font size of the parent. This is where the newly introduced rem by CSS3 triumphs. The rem unit is relative to the root or html element. So you can define a particular font size on the html element, and then the rem units are all defined as percentages of that. Read more about rem in Jonathan Snook’s article, "Font sizing with rem."

Tables: Two techniques

Tables are commonly used to organize and display data in a matrix. Tables do not usually adapt well to changes in form factor or screen size of the viewing device. This is particularly true on mobile devices, where the screen width really tests the minimum required width for a table column. You can zoom out to view the table in its entirety, in which case the text size may be too small to read. Or, you can zoom in for a better view of data, but with lots of scrolling needed, both horizontally and vertically.

Let's look at two techniques to get around these issues and achieve responsive display for typical data tables in portlets.

Creating a responsive table that maintains data

One of RWD's core principles is to remove horizontal scrolling altogether. So let's convert the table from something that spans horizontally to something that grows vertically. All values of each row of the table will be stacked vertically on top of each other. Not only will the rows grow vertically down, they will also grow vertically down as a name-value pair, where name is the table header for a particular cell, and value is the value in that cell.

Listing 3. Simple table markup
<table>
 	<thead>
		<tr>
			<th>First Name</th>
			<th>Middle Name</th>
			<th>Last Name</th>
		</tr>
	</thead>
	<tbody>
                     <tr>
			<td>Alex</td>
			<td>M</td>
			<td>Kay</td>
		</tr>
		<tr>
			<td>Allie</td>
			<td>A</td>
			<td>Singh</td>
		</tr>
	</tbody>
</table>

This table renders as:

Simple HTML table rendered

Now, to achieve responsiveness using CSS styling, remove the entire table structure by setting display as block. Add this style block to the table markup:

table,tbody,thead,th,tr,td {
		display: block;
}

The table layout is changed to:

Rendering after table structure is removed

As you can see, the table has started to flow downwards with its rows stacking on each other. But the table needs some finishing touches. Get rid of the table headers by adding the following style:

thead tr {
		position: absolute;
		top: -100px;
	           left: -100px;
         }

Now the table renders like this:

Rendering after table headers are removed

Next, add padding to the table values so they appear in the middle of the page:

td {
		position: relative;
		padding-left: 50%;
}

Now the table renders like this:

Rendering after padding is added

Now we can start inserting the table headers for the table row values above. Use the CSS before and nth-type-of() selectors to insert the table header “First Name” as content before the td that contains first names:

td:nth-of-type(1):before {
		content: "First Name";
	}

Now the table renders like this:

Rendering after table headers are added

“First Name” labels now appear beside the first name values in the table. Let's do bit more formatting. Format the “First Name” labels using the before selector so that they are the first thing in a row:

td:before {
		position: absolute;
		top: 1px;
		left: 1px;
	}

Now the table renders like this:

Rendering after table labels are formatted

Similarly, let's add labels for “Middle Name” and “Last Name”:

td:nth-of-type(2):before {
		content: "Middle Name";
	}
td:nth-of-type(3):before {
		content: "Last Name";
	}

Now the table renders like this:

Rendering after table labels are formatted

Let's make the rows more readable by alternating row colors.

 tr:nth-child(even) {
	background-color: lightgray;
}

Now the table renders like this:

Rendering after table labels are formatted

Now let's bring the above styles together with the CSS media queries:

Listing 4. Sample code for responsive tables
/* Styles for screen sizes less than 800px, like tablets */
@media screen and (max-width: 800px) {
	table {
		font-size: 1.2em;
	}
	th {
		padding: 4px;
	}
}

/* Styles for screen sizes less than 480px, like landscape mode in smartphones */
@media screen and (max-width: 480px) {
	table,tbody,thead,th,tr,td {
		display: block;
	}
	thead tr {
		position: absolute;
		top: -100px;
		left: -100px;
	}
	td {
		position: relative;
		padding-left: 50%;
	}
	td:before {
		position: absolute;
		top: 1px;
		left: 1px;
	}
	td:nth-of-type(1):before {
		content: "First Name";
	}
	td:nth-of-type(2):before {
		content: "Middle Name";
	}
	td:nth-of-type(3):before {
		content: "Last Name";
	}
	td:nth-of-type(4):before {
		content: "Email";
	}
	td:nth-of-type(5):before {
		content: "Phone";
	}
	td:nth-of-type(6):before {
		content: "Address";
	}
	td:nth-of-type(7):before {
		content: "ZipCode";
	}
	td:nth-of-type(8):before {
		content: "City";
	}
	td:nth-of-type(9):before {
		content: "State";
	}
}

Additional table headers may be defined as follows:

<thead>
	<tr>
		<th>First Name</th>
		<th>Middle Name</th>
		<th>Last Name</th>
		<th>Email</th>
		<th>Phone</th>
		<th>Address</th>
		<th>ZipCode</th>
		<th>City</th>
		<th>State</th>
	</tr>
</thead>

Notes:

  • According to our table width, the tables display well on both desktops and tablets. But you may want to increase font size a bit for tablets (as shown in the max-width: 800px media query).
  • We chose to handle responsiveness starting with landscape mode for mobile devices (max-width: 480px). Thus, most of the CSS magic happens inside this particular media query only.
  • We essentially removed the tabular display by setting display none. We then show each row in a 2-column layout, where the left column header and the right column is the value. We use td:before to achieve this.
  • Because we have not done anything specific for mobile devices in portrait mode, the same styling of landscape mode will ensure the table is displayed as is, and optimized and responsive at max width 320px too.

Here is our table at multiple resolutions. As the screen size reduces, the data table gracefully adapts.

Figure 1. Our table on a desktop browser (not shown to scale)
Rendering on a desktop device

Click to see larger image

Figure 1. Our table on a desktop browser (not shown to scale)

Rendering on a desktop device
Figure 2. Our table on a tablet browser (not shown to scale). Notice the responsive theme.
Rendering on a tablet

Click to see larger image

Figure 2. Our table on a tablet browser (not shown to scale). Notice the responsive theme.

Rendering on a tablet
Figure 3. Our table on a mobile browser (not shown to scale). The table flows vertically.
Rendering on a mobile device

Click to see larger image

Figure 3. Our table on a mobile browser (not shown to scale). The table flows vertically.

Rendering on a mobile device

Creating a responsive table that gracefully hides data

As the screen size or form factor decreases, the real estate available to a data table decreases as well. Thus, for our second technique, let's incrementally hide relatively insignificant columns. Let's also adapt the text size, increasing it as we go down screen sizes.

We'll use the same table design:

<thead>
	<tr>
		<th>First Name</th>
		<th>Middle Name</th>
		<th>Last Name</th>
		<th>Email</th>
		<th>Phone</th>
		<th>Address</th>
		<th>ZipCode</th>
		<th>City</th>
		<th>State</th>
	</tr>
</thead>

And we'll make these design decisions:

  • On a desktop browser, we'll show the entire table.
  • For a mobile browser in landscape layout, we'll show only First Name, Last Name, Email, and Phone, based on the assumption that these are relatively more essential than Address in this context.
  • For a mobile browser in portrait layout, we'll show only First Name, Last Name, and Email. We'll also use shorter table headers to save as much real estate as possible.

To achieve this kind of responsiveness for our table, we'll use these CSS media queries:

Listing 5. CSS media queries for hiding table data
/* Default styles for screen sizes > 800px */
tr:nth-child(even) {
	background-color: lightgray;
}
table {
	border-collapse:collapse;
}
th {
	background-color: lightblue;
	padding:5px;
}
.mobile_portrait {
	display: none;
}

/* Styles for screen sizes less than 800px, like tablets */
@media screen and (max-width: 800px) {
	table { 
		font-size: 1.2em;
	}
	th {
		padding:4px;
	}
}
/* Styles for screen sizes less than 480px, like landscape mode in smartphones */
@media screen and (max-width: 480px) {
	table { 
		font-size: 1.4em;
		width:100%;
	}
	.tab {
		display: none;
	}
	.inputBtn {
		font-size: 1.4em;
	}
}

/* Styles for screen sizes less than 320px, like portrait mode in smartphones */
@media screen and (max-width: 320px) {
	.mobile_landscape {
		display: none;
	}
	.mobile_portrait {
		display: table-cell;
	}
	
}

Some table fields may be defined as follows:

<thead>
	<tr>
		<th class="mobile_landscape">First Name</th>
		<th class="tab">Middle Name</th>
		<th class="mobile_landscape">Last Name</th>
		<th class="mobile_portrait">F Name</th>
		<th class="mobile_portrait">L Name</th>
		<th>Email</th>
		<th class="mobile_landscape">Phone</th>
		<th class="tab">Address</th>
		<th class="tab">ZipCode</th>
		<th class="tab">City</th>
		<th class="tab">State</th>
	</tr>
</thead>

Notes:

  • All table columns are shown for any device display with a width greater than 800 px. Of course, you may set higher breakpoints too and handle them accordingly.
  • The first media query section in the styles is for an 800 px screen width, which is largely tablet territory. To optimize for this display, just increase the font size and re-style with same content.
  • Determine which columns are non-essential and may be sacrificed for a better table display on a smartphone screen in landscape mode (max width 480 px). Assign those columns a class tab and set their display to none. Also increase the font size and button size to increase readability.
  • On mobile devices viewed in portrait mode, there is even less real estate available. You can do additional things like reducing column header string lengths to preserve as much space as possible. For example, we have another set of column headers that have been hidden until now, but are shown at this width (set CSS class “mobile_portrait”). The enlargement of text and input controls is done as usual.

Here is the table at multiple resolutions. As the screen size reduces, the data table gracefully adapts.

Figure 4. Our table on a desktop browser (not shown to scale)
Our table on a desktop browser

Click to see larger image

Figure 4. Our table on a desktop browser (not shown to scale)

Our table on a desktop browser
Figure 5. Our table on a tablet browser (not shown to scale). Notice the responsive theme.
Our table on a tablet browser (not shown to scale). Notice the responsive theme.

Click to see larger image

Figure 5. Our table on a tablet browser (not shown to scale). Notice the responsive theme.

Our table on a tablet browser (not shown to scale). Notice the responsive theme.
Figure 6. Our table on a mobile browser, landscape mode (not shown to scale). We show only the most important fields.
Our table on a mobile browser, landscape mode (not shown to scale). Notice the responsive theme.

Click to see larger image

Figure 6. Our table on a mobile browser, landscape mode (not shown to scale). We show only the most important fields.

Our table on a mobile browser, landscape mode (not shown to scale). Notice the responsive theme.
Figure 7. Our table on a mobile browser, portrait mode (not shown to scale). Notice we have fewer columns and shorter column headers.
Our table on a mobile browser, portrait mode (not shown to scale). Notice the responsive theme.

Click to see larger image

Figure 7. Our table on a mobile browser, portrait mode (not shown to scale). Notice we have fewer columns and shorter column headers.

Our table on a mobile browser, portrait mode (not shown to scale). Notice the responsive theme.

Forms

Like data tables, forms are equally popular for portlet applications and require optimization for mobile devices. There are many ways to handle multi-channel form display using RWD techniques.

Our approach will use media queries to incrementally adapt the form for various screen sizes. We will:

  • Vertically align labels and fields. For mobile display, labels and fields flowing vertically without taking up any horizontal space are ideal. This makes it easy to read labels while filling in information. Long labels can be challenging due to limited real estate available.
  • Use mobile-friendly input types to enhance form usability. For example, if you have fields like email and phone, you may want to use types email and tel for those. This ensures that the appropriate keypad layout will be displayed for the field selected.
  • Increase the text size to aid readability on small mobile devices screens.
Listing 6. Sample style for a responsive form
/* Default styles for all screen sizes */
/* These styles achieve form layout */
* {
	-webkit-box-sizing: border-box;
	-moz-box-sizing: border-box;
	box-sizing: border-box;
} 
form > div {
	clear: both;
	overflow: hidden;
	padding: 1px;
	margin: 0 0 10px 0;
}
form > div > label {
    text-align: right;
}
form > div > label {
    float: left;
    padding-right: 10px;
    width: 25%;
}
form > div > div {
    float: right;
    width: 75%;
}
input[type=text],
input[type=email],
input[type=tel]
{
	width: 50%;
}

/* Styles for screen sizes less than 480px, like landscape and portrait mode in smartphones */
@media (max-width: 480px) {
	form{
		font-size: 1.6em;
	}
	form > div > label, 
	form > div > div{
		width: 100%;
		float: none;
	}
	input[type=text],
	input[type=email],
	input[type=tel],
	input[type=submit]
	{
		width: 100%;
		font-size: 1em;
	}
}
</style>
Listing 7. Sample form using the styles and other RWD principles
<form id="form" name="form" method="POST" action="<portlet:actionURL/>">
<div>
	<label for=”firstname”>First Name </label>
	<div> 
		<input type="text" name="firstname" id="firstname" />
	</div> 
</div>
<div>
	<label for=”lastname”>Last Name </label>
	<div> 
		<input type="text" name="lastname" id="lastname" />
	</div> 
</div>
<div>
	<label for=”email”>Email</label> 
	<div>
		<input type="email" name="email" id="email" /> 
	</div>
</div>
<div>
	<label for=”phone”>Phone</label> 
	<div>
		<input type="tel" name="phone" id="phone" />
	</div>			
</div>
<div>
	<div>
		<input type="Submit" name="submit"  
				value="Register"></input>
</div>
</div>
</form>

Notes:

  • The entire form is displayed on any device with width greater than 800 px. Of course, you may set higher breakpoints and handle them accordingly. All the styles used are standard patterns to achieve the form layout without resorting to HTML tables, which degrade performance when used only for layout purposes.
  • As previously mentioned, we accommodate both landscape and portrait mode for mobile devices (max width 480 px will handle 320 px as well). We change the form layout from a left label form to a top label form, which saves screen real estate, and ensures vertical flow of form fields, which is more readable.
  • We use the concept of em (see the discussion under Text size) to increase the relative size of the form for smaller screen sizes, making the text more readable on smaller screens.
  • We made the Register button fill the entire horizontal width, as is customary for buttons on mobile displays.

Here is our sample form at multiple resolutions. As the screen size reduces, the form gracefully adapts.

Figure 8. Our form on a desktop browser (not shown to scale)
Our form on a desktop browser (not shown to scale)

Click to see larger image

Figure 8. Our form on a desktop browser (not shown to scale)

Our form on a desktop browser (not shown to scale)
Figure 9. Our form on a mobile browser, slightly enlarged for landscape mode (not shown to scale)
Our form on a mobile browser, slightly enlarged for landscape mode (not shown to scale)

Click to see larger image

Figure 9. Our form on a mobile browser, slightly enlarged for landscape mode (not shown to scale)

Our form on a mobile browser, slightly enlarged for landscape mode (not shown to scale)
Figure 10. Our form on mobile browsers, portrait mode (not shown to scale). The relevant keyboard is displayed for different fields.
Our form on a mobile browser, slightly enlarged for landscape mode (not shown to scale)

Click to see larger image

Figure 10. Our form on mobile browsers, portrait mode (not shown to scale). The relevant keyboard is displayed for different fields.

Our form on a mobile browser, slightly enlarged for landscape mode (not shown to scale)

Responsive Web Design vs. different sets of JSPs

RWD is one way to future-proof your UI so that it can adapt seamlessly across devices. Another way is to use separate sets of JSPs that can serve entirely different content for each type of device. This approach involves detecting a device browser, and serving a corresponding JSP that you create for that device. For example, you could have a JSP for desktops, a JSP for tablets, and a JSP for smartphones.

Reasons to use separate sets of JSPs, instead of RWD, include:

  • If you have a mobile version that is more simplistic in scope and functionality than the desktop equivalent, then independent mobile JSPs supporting a radically different design and architecture from the desktop version may be the way to go.
  • If you have a long, complex form, you may need to break the form into multiple pages for the mobile version or even change the UI type entirely. For example, the mobile JSPs may be used to combine multiple form fields into one.
  • UI considerations may demand a different treatment for mobile versions. For example, a list of radio buttons may not be appropriate for mobile devices. Similarly, type-ahead text inputs are more appropriate for long drop-down lists.

WebSphere Portal uses the concept of device classes to help you create separate sets of JSPs in a standard and easy way. To learn how, see Device classes.

Whether to use RWD or different JSPs will depend on your business requirements. The trade-off to consider is while different JSPs give you a specific UI for each device, they also require more development and maintenance. RWD is versatile, low-cost, and a good practical compromise.

Combining RWD and device detection

The main concern with using RWD is over-downloading, where the same data for desktop display is also downloaded for all devices. Smartphones are usually limited in bandwidth, and downloading all of the resources regardless of whether they are needed will hinder performance. On the other hand, serving only device-specific content leads to duplication of resources and extra maintenance. Using a combination can alleviate both of these drawbacks. Targeting the device and delivering the appropriate resources will ensure quality performance, and using RWD will enable reuse of content across devices, eliminating duplication of resources. Using both RWD and device detection, as WebSphere Portal 8.0.0.1 provides, can be a powerful solution for mobile optimization.

Conclusion

From a portlet development point of view, this article has detailed ways to deal with the proliferation of devices that can access your portal site. RWD is one of the most cost-effective and easiest approaches, which we illustrated by applying it to various common UI types such as tables and forms. We also discussed an alternative approach that involves device detection to deliver resources and markup targeted for a particular device via devices classes. The approach used out-of-the-box for WebSphere Portal 8.0.0.1 is a combination of both responsive design and device detection to provide a best-of-breed mobile experience.

Resources

Learn

Get products and technologies

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Mobile development on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Mobile development, WebSphere, Java technology
ArticleID=959102
ArticleTitle=Implement responsive web design using WebSphere Portal, Part 3: Developing multi-channel portlets
publish-date=01072014