Implement responsive web design using WebSphere Portal, Part 1: Getting started with the default theme

Optimize your WebSphere Portal user interface for multiple devices within a single theme

Creating an experience for multiple devices is essential, but targeting the right set of devices can be challenging. Responsive web design (RWD) has become a popular approach for creating a single web site that optimizes content and layout automatically based on screen size, device and orientation, eliminating the need to design for a specific user device preference. This article discusses how to transform your WebSphere Portal theme into a responsive web experience from the ground up. With advanced CSS techniques, you can implement a theme that responds in real time to different screen resolutions using flexible layouts and elastic elements.

Jonathan Lidaka (jjlidaka@us.ibm.com), WebSphere Portal Front-end Engineer, IBM

Jon 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.



Scott Consolatti, WebSphere Portal Front-end Engineer, IBM

Scott Consolatti is a Front-end engineer at IBM's Research Triangle Park Development Lab. During his time in Portal development, he has primarily contributed to theme development with a focus on the new modular theme architecture. He has also previously contributed to various components including widgets, CSA, and personalization. Scott has also contributed to the development of the user interface of many other IBM products including IBM Mashup Center and IBM Lotus ActiveInsight, and has numerous patents related to user interface. Currently he is focused on enabling a mobile experience within the default theme for WebSphere Portal.



09 October 2012

Also available in Japanese Spanish

Introduction

About this series

This series walks you through the steps to develop a user interface within WebSphere® Portal that integrates responsive web design (RWD) concepts. Using responsive design ensures you get the most out of your web design effort, as it provides a way for the user interface to optimize automatically for screen resolution, orientation, or capabilities. Gracefully adapting to these device attributes using elastic elements ensures that your site is usable and ready for future screen sizes.

Creating an exceptional web experience that is optimized across multiple devices is essential for today's business. Users now expect to be able to browse the web on their phones just as easily as on their desktop computer.

Targeting mobile devices usually starts with a conversation about native applications, but these applications have a high cost of ownership and code reuse is limited. Another solution is to create an alternate website specifically for a mobile device, but that is not a practical solution, as you can end up with many code resources to maintain.

Ethan Marcotte published an article discussing a practical solution to the shifting landscape of devices and screen sizes by creating flexible, fluid, and adaptive websites. Read Ethan's influential article on responsive web design (see the Resources later in this article).


Prerequisites

WebSphere® Portal

In developing this article series, we used WebSphere® Portal version 8.0. Most of the code we discuss is core to any theme developer: HTML, CSS, Javascript, and JSP.

Web browser

We recommend that you have at least Mozilla Firefox 4 with the Firebug extension installed. However, any browser with CSS3 support will be able to render these tactics correctly. Most browsers now come with their own development tools built in, but our examples specifically reference Firebug.

WebDAV client

To update a theme in WebSphere Portal, you need a WebDAV client. The sample for this article was developed using AnyClient. You can use any WebDAV client that WebSphere Portal supports. We discuss placing code into files that you have copied to your local machine, and we assume that you do this on your local machine first, then copy it back to WebDAV.

For more details, review this article on connecting to WebDAV: "Connecting to the Portal WebDAV with 8.0."

Custom theme

You need to create your own custom theme before applying the responsive web design tactics. Do not modify the Portal 8.0 theme directly, because this theme can be updated by service fixpacks. Instead, create a copy of the Portal 8.0 theme; this ensures that your theme has all the required elements for the theme to function, and changes will not be overwritten by a fixpack. To create a new custom theme, follow the instructions in this article: "Create a copy of the theme."

You should also be familiar with these concepts discussed in these articles:


Getting started

By default, the WebSphere Portal 8.0 default theme is not optimized for mobile devices. Two essential pieces in creating a responsive Portal theme are:

Media queries
Media queries enable the use of CSS based on orientation, screen size, and other attributes of the device. You can place them on the <link /> element when including CSS or inline directly in the CSS. For this article, we place the queries directly within the CSS to alleviate any extra requests to the server. Using queries is similar to writing if conditions to tell a browser when to enable a certain set of styles.

Fluid elements
A fluid element uses percentages, instead of fixed values, to define container widths. Percentages create an elastic container that will optimize for different form factors. This concept applies to many parts of the theme, such as the navigation, footer, layout containers, and more.

This article focuses on a simple solution that optimizes for different form factors but also takes into account available capabilities. Delivering optimized images for certain devices is also an important piece that will be discussed in later parts of this series.

Using Firebug to inspect areas of the theme

Firebug is an extension for Firefox that provides many developer tools within the browser. Firebug allows you to inspect, edit, and debug CSS, HTML, and Javascript inline on any web page. We use this tool to help us identify static areas of the theme that we need to tweak to make it responsive. If you are not familiar with Firebug, review this article on developerWorks: "Debug and tune applications on the fly with Firebug."


Making the theme responsive

Let's now add responsive elements to the theme. You should have already created a custom theme. Make sure you have a page with the custom theme assigned so that you can view your changes as you go through this article.

Introduction to the WebSphere Portal 8.0 theme styles

The WebSphere Portal themes use a compressed layer for the default styles to increase performance. These styles are stored on WebDAV within the custom theme. The location on WebDAV is: fs-type1:themes/<customTheme>/css/

The layer files are named "master.css" and "masterRTL.css" and are included by the "wp_theme_portal_80" module, which is defined as a theme specific contribution in the file: fs-type1:themes/<customTheme>/contributions/theme.json

These styles define the structure of the page and can be used in any theme that shares the WebSphere Portal 8.0 HTML markup. There are two layers because one is for bidirectional users (masterRTL.css), and the other is for non-bidirectional users (master.css). For the bidirectional version, the page lays out from right to left; these style sheets are used when the page is in a bidirectional language, such as Arabic or Hebrew.

We will update the master.css file directly to include the code that will create a responsive design.

Create the media queries

The media queries optimize the theme for different devices. In this example, we focus on two additional devices other than desktop: a smartphone and tablet. In design, when a media query is introduced, that is often called a breakpoint. You can have multiple breakpoints per device you are targeting, but for this example we ignore orientation changes and other minor breakpoints and focus on one breakpoint for each device.

Connect to the fs-type1 entry point for WebDAV, navigate to your custom theme, and copy the master.css file discussed in the previous section to your local machine. This is a compressed file, so it will only be one really long line of CSS. That is fine, since we want to keep the desktop part of the user interface intact and add additional styles to optimize further.

The first query that you want to add is for a tablet device, so you want to target devices with a screen width less than 800 pixels. Copy the media query below in Listing 1 to the end of master.css.

Listing 1. Media query for screen width less than 800 pixels
@media screen and (max-width: 800px) {

}

Throughout this article, make sure to copy the file back to WebDAV after you make updates, such as adding code to the master.css. With this media query in place, any styles that are placed within the structure will render when the screen size is less than 800 pixels.

The second query to add is for a smartphone device, which targets devices with a screen width less than 480 pixels. Copy the media query below in Listing 2 to the end of master.css.

Listing 2. Media query for screen width less than 480 pixels
@media screen and (max-width: 480px) {

}

With this media query in place, any styles that are placed within the structure will render when the screen size is less than 480 pixels. Listing 3 shows the master.css with these two breakpoints in place.

Listing 3. The master.css file with media queries
.wpthemeMenuAnchor {display:inline-table !important;}.wpthemeMenuBorder {top: -9999px.... 
@media screen and (max-width: 800px) {

}

@media screen and (max-width: 480px) {

}

Update the theme structures to become responsive

You now have two structures set up that contain the styles that override the desktop and optimize the theme for a tablet and smartphone. The first step to identifying areas of the theme that need to become responsive is to use Firebug to inspect the DOM and find the structures that have a set width.

To inspect the DOM, select the arrow button on the right side of the Firebug toolbar (Figure 1).

Figure 1. The Firebug inspector
The Firebug inspector

Using the inspector, you can hover over areas of the page to see the width defined in the styles. As you start to hover over elements on the page, you will notice there is a page wrapper with the style class "wpthemeFrame" (see Figure 2); and within the major areas of the page, such as navigation, main content, and footer, there is a structure with the style class of "wpthemeInner" (see Figure 3).

Figure 2. The page wrapper element
The page wrapper element
Figure 3. The inner structures of the page
The inner structures of the page

These two style classes are defined with static values. You need to change the widths to accurately reflect the device that is targeted and make the structures with the classes defined flexible. To do this, set the min-width on wpthemeFrame to the minimum width you want your responsive design to adapt to (for this sample, it's 320px). Next, make all of the major areas of the page elastic by giving wpthemeInner a percentage width (for this sample, we use 100%). Copy the style definitions for wpthemeFrame and wpthemeInner to the tablet media query defined with a max-width of 800 pixels, as shown in Listing 4. Since these styles will be applied to all screen sizes below 800 pixels, it will apply for both tablet and smartphone devices.

Listing 4. Create responsive structures for wpthemeFrame and wpthemeInner
@media screen and (max-width: 800px) {
	.wpthemeFrame {
		min-width: 320px;
	}
		
	.wpthemeInner { 
		width: 100%;
	}
}

The next items to modify for different devices are the edit mode toggle and project menu (Figure 4).

Figure 4. The Edit mode toggle and project menu
The Edit mode toggle and project menu

If you do not believe users on a tablet or smartphone will require the edit mode capabilities, hiding them from view on these other devices would be appropriate. To do this, simply add a style to hide the elements: Add the CSS from Listing 5 for the "utb-project-quicklink" and "utb-project-info".

Listing 5. Removing edit mode
@media screen and (max-width: 800px) {
	.wpthemeFrame {
		min-width: 320px;
	}
		
	.wpthemeInner { 
		width: 100%;
	}
	.utb-project-quicklink, 
	.utb-project-info {
		display: none;
	}
}

As shown in Figure 5, the page on a tablet will now resize and hide the edit capabilities.

Figure 5. Edit capabilities are hidden
Edit capabilities are hidden

Another element of the page that you might want to control as you optimize for smaller screen sizes is the amount of navigation that is displayed to the user. In this sample, we hide the top navigation from rendering on screen sizes below 480 pixels. We also remove the search input box from the smartphone optimization to save screen real estates. To do this, simply use the same approach as you did with the edit mode toggle and set a style to hide these elements. Add the code in bold from Listing 6 to the media query targeted for smartphones.

Listing 6. Removing top navigation
@media screen and (max-width: 480px) {
	.wpthemeHeader,
	.wpthemeSearch {
		display:none;
	}
}
Figure 6. Top navigation and search are hidden for a smartphone
Top navigation and search are hidden for a smartphone

Using styles to hide markup for responsive design is quick and easy, and in some cases might be the best approach. The advanced section below discusses how to set up logic so that, instead of using styles, you can leverage device classes to control markup that is rendered.

When optimizing the theme for smaller devices, it is important to take into account that the input mechanism will change as well. These tablet and smartphone devices allow a user to use touch events to select items on the page. You want to make sure that elements on the page are easily selectable using a finger. One area of the page that becomes very congested on smaller screen sizes is the footer. To alleviate this congestion and allow for easier touch events, you want to make sure the footer has proper spacing. This requires adding more space around the footer links, increasing the font size, and making sure the columns are elastic. Add the code in Listing 7 to the tablet media query (in other words, max-width: 800px).

Listing 7. Add proper spacing to page footer
	.wpthemeFooter li { 
		margin: 10px 0;
	}
	
	.wpthemeFooter a{
		font-size: 1.25em
	}
	
	.wpthemeFooterCol {
		width: 30%;
		padding: 0 1%;
	}
	
	.wpthemeCol {
		margin-left: 0;
	}
Figure 7. Page footer has proper spacing for smaller devices
Page footer has proper spacing for smaller devices

Smartphones provide less real estate than a desktop or tablet, so it is more difficult to display items side by side while still making it easy to determine the different areas of the page and to use touch events. You want to stack some elements of the page so that they are optimized for smartphones. The areas of the page to optimize in this manner are navigation, layout, and footer.

For the layout, it makes sense to optimize the containers for both tablet and smartphone. This sample targets the out-of-box layouts that have all columns. Also, make sure to add some content to the page so you can see how the portlets stack for different screens sizes or device. Copy the code from Listing 8 into the tablet media query for stacking the layout, and it will apply to all devices with a screen width under 800 pixels. See Figure 8.

Listing 8. Styles to stack the layout containers
.wpthemePrimaryContainer.wpthemeCol,
.wpthemeSecondaryContainer.wpthemeCol,
.wpthemeTertiaryContainer.wpthemeCol {
	padding: 0 2.5%;
	width: 95%;
}

For stacking navigation and footer, apply this only to smartphone devices. Copy the code in Listing 9 to the smartphone media query. See Figure 8.

Listing 9. Styles to stack the navigation and footer
.wpthemeCommonActions.wpthemeRight,
.wpthemePrimaryNav.wpthemeLeft {
	clear:both;
}

.wpthemeBanner .wpthemeNavContainer1,
.wpthemePrimaryNav.wpthemeLeft,
.wpthemeNavListItem.wpthemeLeft,
.wpthemeNavListItem a{
	float: none;
}

.wpthemePrimaryNav .wpthemeNavListItem {
	background: -moz-linear-gradient(top, #474747 0%, #111111 100%); 
	background: -webkit-gradient(
		linear, left top, left bottom, 
		color-stop(0%,#474747), color-stop(100%,#111111));
	border-top: 1px solid #1A1A1A;
}

.wpthemePrimaryNav li a,
.wpthemePrimaryNav li a :focus,
.wpthemePrimaryNav li a:hover,
.wpthemePrimaryNav li a:active,
.wpthemePrimaryNav .wpthemeSelected a, 
.wpthemePrimaryNav .wpthemeSelected a:focus, 
.wpthemePrimaryNav .wpthemeSelected a:hover,
.wpthemePrimaryNav .wpthemeSelected a:active {
	padding: 10px;
}

.wpthemeFooter{
	margin: 0 2.5%;
}

.wpthemeFooterCol {
	width:100%;
	padding:0
}
Figure 8. The primary navigation, layout, and footer are stacked for smartphone devices
The primary navigation, layout, and footer are stacked for smartphone devices

Click to see larger image

Figure 8. The primary navigation, layout, and footer are stacked for smartphone devices

The primary navigation, layout, and footer are stacked for smartphone devices

Stacking the navigation links produces a pattern that is typical on smartphone devices; however, it is not always clear if clicking on the link will take you to a new page or if content will expand and collapse when selecting the link. To clarify for the user that these links will change context of the page, add arrows to the page section. To do this, you need to add a new image on WebDAV. The image is named "arrow.png" and is located in the sample files available in the Downloads section of this article. Once you download the image, place the image in this location on WebDAV: fs-type1:themes/<customTheme>/css/images/

The file structure after copying the image to WebDAV will look like Figure 9.

Figure 9. The new arrow image on WebDAV
The new arrow image on WebDAV

After the image is on WebDAV, you can use this image in the styles. You want to add the image to the navigation links, and you already have a definition in the master.css under the smartphone media query. Add a new background attribute to the definition for the primary navigation links as shown in Listing 10.

Listing 10. Adding the arrow to the primary navigation on a smartphone
.wpthemePrimaryNav li a,
.wpthemePrimaryNav li a :focus,
.wpthemePrimaryNav li a:hover,
.wpthemePrimaryNav li a:active,
.wpthemePrimaryNav .wpthemeSelected a, 
.wpthemePrimaryNav .wpthemeSelected a:focus, 
.wpthemePrimaryNav .wpthemeSelected a:hover,
.wpthemePrimaryNav .wpthemeSelected a:active {
	background: url(images/arrow.png) no-repeat scroll right center transparent;
	padding: 10px;
}

Once you have the new background attribute in place, you should be able to refresh the page and see the arrows displayed on the right side of the navigation link area, as you can see in Figure 10.

Figure 10. Smartphone navigation
Smartphone navigation

Set the correct viewport for devices

Smartphone browsers often scale web pages to a wide viewport width, one that is appropriate for displaying markup targeted for desktop devices. You want to make sure that unintentional gestures do not scale the theme in a manner that makes it difficult to use.

The meta tag example below in Listing 11 automatically makes the width equal to the width of the device's screen. The initial-scale property will set the zoom level when the page is first loaded. The maximum-scale and minimum-scale properties will set the parameters of the zooming functionality on the device, and with the minimum and maximum set to the same initial scale, the user will not have the ability to zoom in or out on the page. This is acceptable as we plan to optimize the user interface for smaller screens, and a truly optimized responsive design should not need zooming functionality.

Listing 11. Set the viewport to disable device scaling
<meta name="viewport" content="width=device-width, initial-scale=1, 
maximum-scale=1, minimum-scale=1">

Include the meta tag above (Listing 11) in the <head> element of the theme. You can do this by connecting to the fs-type1 entry point for WebDAV and navigating to your custom theme's theme.html template. Assuming you are using the default templates that are localized, they would be in this location: fs-type1:themes/<customTheme>/nls/

Copy the theme_en.html file to your local machine and open it. Find the <head> element in the template, which should look like Listing 12 below.

Listing 12. Head element of the theme template
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<!-- rel=dynamic-content indicates an element that is replaced with the contents 
produced by the specified href. dyn-cs:* URIs are resolved using the 
WP DynamicContentSpotMappings resource environment provider. These values can
also be set using theme metadata if a theme is specified in the URI 
(e.g. @tl:oid:theme_unique_name). -->
<link rel="dynamic-content" href="co:head">
<link rel="dynamic-content" href="dyn-cs:id:80theme_head">
<!-- rendering is delegated to the specified href for each locale -->
</head>

Place the meta tag example in the <head> element of the theme template (Listing 13) and copy back to WebDAV.

Listing 13. Head element of the theme template
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1, 
maximum-scale=1, minimum-scale=1">
.
.
.
</head>

The theme now fills the appropriate space on all devices and the zooming capabilities are disabled.


Advanced: Modifying dynamic content

In the previous section, you learned how to hide certain elements via display:none styles controlled by media queries in the theme's static css resources. For performance, it will be better to completely remove those elements from the page for certain devices so that the size of the response to the device is as small as possible.

Completely removing an element from a page for certain devices can be accomplished using the DeviceClass of the ClientProfileBean of the Portal Expression Logic (EL) Beans. EL Beans can be used in the theme's JSP resources and allow the presentation layer to communicate with the application layer, such as the Portal Model API.

Unlike the theme's static resources, which are available through WebDAV, the theme's dynamic jsp resources are available through the theme's enterprise application (ear), as they require access to the servlet context to compile and execute.

The theme's dynamic jsp resources are linked to the theme's static resources in theme.html through dynamic content spots. For more explanation, see Working with dynamic content spots.

Creating a new set of dynamic content

Before continuing, make sure you have fully completed all of the steps and subsections to Create a copy of the theme when you created your own custom theme at the beginning of this article.

The subsection Copy the dynamic resources for your theme explained how to create your own theme ear with the jsps.

The subsection Bind your theme to the context root of the web app explained how to register the context root of your theme's ear with the Portal server.

The subsection Modify the dynamic resource references for your theme explained how to create your own custom dynamic content spots.

Putting it all together:

  • The dynamic content spot appears in theme.html in the form of a dyn-cs anchor tag, such as <a rel="dynamic-content" href="dyn-cs:id:customTheme_commonActions"></a>.
  • The dyn-cs id, such as customTheme_commonActions, maps to the custom property in the WP DynamicContentSpotMappings resource environment provider (REP) in the WebSphere Integrated Solutions Console.
  • And then, the value of the custom property, such as res:/customTheme/themes/html/dynamicSpots/commonActions.jsp, maps to the dynamic jsp resource in your theme's ear.

It is this commonActions.jsp that we use as an example of updating dynamic content with EL Beans.

Example of updating dynamic content with EL Beans

Locate and edit the commonActions.jsp file of your custom theme at <wp_profile>\installedApps\<cell>\<CustomThemeEAR>.ear\<CustomTheme>.war\themes\html\dynamicSpots.

The first tag that you want to add is a c:set tag to set the current device type in a variable named deviceClass using the DeviceClass of the clientProfile EL bean. Add the line in Listing 14 at the top of your file after the includes.

Listing 14. EL bean for getting the current device type
<%-- Renders links for Login/Logout and Help that are shown in the banner --%>
<c:set var="deviceClass" scope="request" value="${wp.clientProfile['DeviceClass']}" />

	<ul class="wpthemeCommonActions wpthemeRight">

Now you are ready to conditionally remove certain elements of the page. First, remove the username link for editing the user profile on smartphones. To do so, add a c:if tag around the block of code you want to remove, using the deviceClass variable in the comparison. Add the two lines in Listing 15 around the username link <li> block.

Listing 15. If block for removing username link based on device type
<c:if test="${deviceClass != 'smartphone'}">
<li class="wpthemeFirst">	
<portal-internal:adminlinkinfo name="SELFCARE">
<portal-navigation:urlGeneration contentNode="<%=wpsContentNode%>" 
	layoutNode="<%= wpsCompositionNode %>" 
	portletWindowState="Normal" 
	themeTemplate="" 
	portletParameterType="render">
<portal-navigation:urlParam type="render" name="ao" value="thm"/>
<portal-navigation:urlParam type="render" name="OCN" 
	value="<%= wpsNavigationNodeID %>" />
	<a href="<%wpsURL.write(escapeXmlWriter);%>">
		<c:out value="${wp.user[themeConfig['user.displaynameattribute']]}" />
	</a>
   </portal-navigation:urlGeneration>
   </portal-internal:adminlinkinfo>
</li>
</c:if>

The out-of-box device types are desktop, tablet, and smartphone. You can configure additional device types, so you can have any number of device types over time. Learn more in this article: Device Classes.

The next thing you want to do is to remove the Actions menu link on smartphones and tablets. Add the two lines in Listing 16 around the Actions menu <li> block.

Listing 16. If block for removing Actions menu based on device type
<c:if test="${(deviceClass != 'tablet') && (deviceClass != 'smartphone')}">
<li>
<%--
This creates the Actions context menu for page actions.  We use the
&#36; HTML entity to encode the $ character so that it won't be interpreted
as a JSP expression here and will show up as literals.
--%>
.
.
.
</li>
</c:if>

The last thing you want to do is to remove the Sign Up link on smartphones. Add the two lines in Listing 17 around the Sign Up <li> block.

Listing 17. If block for removing Sign Up link based on device type
<c:if test="${deviceClass != 'smartphone'}">
<li class="wpthemeFirst">
	<portal-internal:adminlinkinfo name="SELFCARE">
	<portal-navigation:urlGeneration allowRelativeURL="true" 
		contentNode="<%=wpsContentNode%>" 
		layoutNode='<%= wpsCompositionNode %>' 
		portletWindowState="Normal" 
		themeTemplate="">
	<portal-navigation:urlParam type="render" name="ao" value="thm"/>
	<portal-navigation:urlParam type="render" name="OCN" 
	   value="<%= wpsNavigationNodeID %>" />
		<a href='<% wpsURL.write(escapeXmlWriter); %>'>
			<portal-fmt:text key="link.enrollment" bundle="nls.engine"/>
		</a>
	</portal-navigation:urlGeneration>
	</portal-internal:adminlinkinfo>
</li>
</c:if>

If you have jsp reloading enabled in your theme's ear, your jsp changes will appear automatically the next time you load your page. If you don't have jsp reloading enabled, the quickest alternative is to delete the compiled jsp's class file, _commonActions.class from the temp folder at <wp_profile>\temp\<cell>\WebSphere_Portal\<CustomThemeEAR>\<CustomTheme>.war\themes\html\dynamicSpots. After you delete that class file, your jsp will recompile and you will see your changes the next time you load your page. Alternatively, you could also restart your theme's web app to see your changes.

The sample files available in the Downloads section of this article provide additional styles that help make a few more areas of the theme responsive, such as the secondary navigation shown in the figures below.

Now your page running on a tablet will look like Figure 11. Notice there is no Actions menu. And the markup for the element is not hidden, but rather is completely removed from the page, which is best for performance.

Figure 11. The responsive theme on a tablet device
The responsive theme on a tablet device

Your page running on a smartphone will look like Figure 12. Notice there is no username link and no Actions menu. And the markup for the element is not hidden, but rather is completely removed from the page, which is best for performance.

Figure 12. The responsive theme on a smartphone device
The responsive theme on a smartphone device

Summary

This first article in the series took you through the basics of developing a theme that integrates responsive web design concepts. You now have a custom theme that automatically adapts to different devices.

Responsive design allows you to have a mobile presence without significant additional expense, but there is more to consider in responsive design than just screen real estate. The next parts of this series show you how to leverage device capabilities such as touch events and content prioritization to create a truly exceptional web experience.


Download

DescriptionNameSize
Responsive design sample filesrwd_sample_files.zip10KB

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


  • Bluemix Developers Community

    Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.

  • Mobile weekly

    Innovations in tools and technologies for mobile development.

  • DevOps Services

    Software development in the cloud. Register today to create a project.

  • IBM evaluation software

    Evaluate IBM software and solutions, and transform challenges into opportunities.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Mobile development, WebSphere, Java technology
ArticleID=839604
ArticleTitle=Implement responsive web design using WebSphere Portal, Part 1: Getting started with the default theme
publish-date=10092012