Implement responsive web design using WebSphere Portal, Part 2: Using device classes to develop for specific devices

Optimize your WebSphere Portal user interface for multiple devices via device classes

Using responsive web design has become a popular approach for creating a single web site that optimizes content and layout automatically by relying on the use of CSS media queries. This article discusses how to leverage the device class mechanism in WebSphere Portal to filter resources and optimize the resource aggregation within the theme for certain devices. These techniques will make your responsive theme perform better and give the user a more consistent experience.

Share:

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.



David Nixon (david_nixon@us.ibm.com), WebSphere Portal Chief Programmer, IBM

David Nixon is the Chief Programmer for WebSphere Portal 8.0.0.1. David has worked in Portal and Portal Express for many years and has contributed code in many areas including theme development, virtual portal features, and deployment scenarios.



07 May 2013

Also available in Japanese

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.

For typical responsive user interfaces, the client requests the CSS that optimizes the user interface across devices. But this can mean downloading a large amount of data to a mobile device without sufficient bandwidth. In most cases, it's not necessary to include all styles for all devices, because a small-screen device would never make use of media queries that apply to large screens, for example.

Furthermore, it's rarely worthwhile to include all of the styles required to optimize for a small screen size on a desktop, since most users do not browse with this resolution. Instead, they resize temporarily to view the content alongside another application. Most users do not expect content to be optimized for a screen width of 320 pixels or even 480 pixels on a desktop monitor, but they do when using a mobile device of such resolution.

Part 1 of this series showed you how to use device classes to toggle the visibility of elements in the common actions of the theme. The device class was fetched using JSP expression logic, and for certain devices these elements are not rendered.

Part 2 of the series explores the additional control that device classes provide to create an exceptional responsive experience. This article shows how to target resources for particular mobile devices, as well as how to filter the navigation so that only a subset of pages are displayed based on device. Together, the techniques in Parts 1 and 2 will make your theme perform better and give the user a more consistent experience.


Prerequisites

Review the previous article in this series, as we will now build on the custom theme we created.

WebSphere® Portal

In developing this article series, we used WebSphere® Portal version 8.0. And, specifically for this article, the 8.0.0.1 fixpack is required. After migration to 8.0.0.1, you will need to enable the new responsive design features using the "enable-new-8001-features" configuration task. See the WebSphere Portal documentation for installation instructions.

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. Another extension that will be used in this article is User Agent Switcher.

WebDAV client

To update the WebSphere Portal theme with Worklight JavaScript, you need a WebDAV client. The sample for this article was developed using AnyClient. You can use any WebDAV client that WebSphere Portal supports. See "Connecting to the Portal WebDAV with 8.0" for details.


Getting started

Device classes are used in WebSphere Portal as an abstraction for grouping devices with common properties together. In the previous article, you learned how to use the Theme EL bean to fetch the device class and use it for visibility within a dynamic content spot. In this article, you will use the default device classes provided with WebSphere Portal to filter and optimize resources of Portal for users of a certain device.


Using modularized styles filtered by device class in the theme

Create device-specific styles

In the first article of the series, all of the responsive styles were placed within the master CSS layer in your custom theme on webdav. To make the styles device specific, you need to break the styles for each media query into separate files.

  1. Create two new CSS files that will be used for tablet and smartphone devices. These files will be based on the master.css file that was modified in the previous article. Copy the master.css file located at:
    fs-type1:themes/<customTheme>/css/master.css
  2. Paste the file in the same location if possible, or another location and copy into the same folder, and rename to master_tablet.css
  3. Paste the file again in the same manner as before, and rename to master_smartphone.css
  4. Open the master.css
  5. The master.css file includes the styles for desktop, which are already compressed and minified, as well as two media queries targeted for tablet and smartphone devices.

    Locate the media query for tablet devices within master.css that is defined for a max width of 800 pixels, as well as the media query for smartphone devices that is defined for a max width of 480 pixels. See Listing 1.
    Listing 1. The tablet and smartphone media queries
    /* tablet devices */
    @media screen and (max-width: 800px){
    ...
    }
    /* smartphone devices */
    @media screen and (max-width: 480px){
    ...
    }
  6. Delete both media queries from master.css, as this file is required to render styles for desktop devices only.
  7. Open master_tablet.css.
  8. Locate the media query for smartphone devices within master_tablet.css. See Listing 2.
    Listing 2. The smartphone media query
    /* smartphone devices */
    @media screen and (max-width: 480px){
    ...
    }
  9. Delete the smartphone media query from master_tablet.css as this file is required to render for tablet devices only. There is no need to modify the master_smartphone.css file, as both media queries are required to render the optimized look and feel on that device. The smartphone styles augment the styles set in the tablet media query. However, you could certainly filter these to remove any unwanted tablet styles if you desire.

To share common styles between the three files, you could use an import statement. The common example would be to import the desktop styles into the tablet and smartphone files, and leave the media queries. You could import the desktop styles using this line of code:
@import url("master.css");

This task is optional and not required to successfully implement a responsive design, but it does help with code maintenance. At this point, you now have three files in the CSS folder of your custom theme that will be defined in the theme modules to render for specific devices.

Update theme modules to use device-specific resources

The theme optimization framework in Portal 8.0.0.1 has been augmented to include a mechanism to filter resources based on device. The next step is to update the theme modules to define device-specific contributions for the master CSS layer in your custom theme.

  1. Open the theme.json module contributions file, located at:
    fs-type1:themes/<customTheme>/contributions/theme.json
  2. In the theme.json file, locate the wp_theme_portal_80 module. See Listing 3.
    Listing 3. The wp_theme_portal_80 module in theme.json
    {
    "id":"wp_theme_portal_80",
    	"prereqs":[{
    		"id":"wp_client_main"
    	},{
    		"id":"wp_client_ext"
    	}],
    	"contributions":[{
    		"type":"head",
    		"sub-contributions":[{
    			"type":"js",
    			"uris":[{
    				"value":"/js/head.js"
    			}]
    		}, {
    			"type":"css",
    			"uris":[{
    				"value":"/css/master.css"
    			}, {
    				"value":"/css/masterRTL.css",
    				"type":"rtl"
    			}]
    		}]
    	}]
    }
  3. You can see that the wp_theme_portal_80 module includes the contribution for the master CSS layer under the head contributions. Currently the master.css contribution is not device-specific, and the same file is used for all devices, depending on the language. Similar to the type attribute used to specify the file to include for bi-directional languages, Portal 8.0.0.1 introduced a new attribute to specify the device class that a file will be included for, named deviceClass. Add the new contributions for both tablet and smartphone, as shown in Listing 4.
    Listing 4. The tablet and smartphone CSS contributions added to theme.json
    {
    "id":"wp_theme_portal_80",
    	"prereqs":[{
    		"id":"wp_client_main"
    	},{
    		"id":"wp_client_ext"
    	}],
    	"contributions":[{
    		"type":"head",
    		"sub-contributions":[{
    			"type":"js",
    			"uris":[{
    				"value":"/js/head.js"
    			}]
    		}, {
    			"type":"css",
    			"uris":[{
    				"value":"/css/master.css"
    			}, {
    				"value":"/css/masterRTL.css",
    				"type":"rtl"
    			},{
    				"value":"/css/master_tablet.css",
    				"deviceClass":"tablet"
    			},{
    				"value":"/css/master_smartphone.css",
    				"deviceClass":"smartphone"
    			}]
    		}]
    	}]
    }
  4. If you have development mode turned on, then after adding the new contributions, they should be ready to use. If you do not have development mode turned on, then restart the Portal server.

    You can enable development mode by setting the resourceaggregation.development.mode property to true within the WP ConfigService resource environment provider (REP). The WP ConfigService REP can be found within the WAS console under: Resources > Resource Environment > Resource Environment Providers.

Test the device class-specific styles in the theme

To test the new device-specific module contributions and ensure that the correct CSS file is being pulled in by the resource aggregator, you should use a browser where you can monitor the requests and change the user agent. In this article, we'll use the Firefox browser with the Firebug and User Agent Switcher extensions.

  1. Enable the theme modularization trace string to display the individual files included on a page. To do this, navigate to Administration > WebSphere Portal > Portal Analysis > Enable Tracing. Then add this trace string to the Enable Tracing portlet:
    com.ibm.wps.resourceaggregator.CombinerDataSource.RemoteDebug=all
  2. Assign your custom theme to a page, and render with your non-mobile device. In the previous article, you could resize the browser and see the content optimize dynamically. Since we removed the media queries from the default master.css file, this should not occur with the new device-specific styles.
  3. Select a tablet device from the User Agent Switcher extension in Firefox (see Figure 1). If you recently installed the User Agent Switcher, you will want to add devices to the extension. For more assistance with adding devices, you can access help on the extension author’s website.
    Figure 1. Selecting a tablet device from user agent switcher
    Screen capture showing the drop-down selections for tablets
  4. Open the Firebug panel and refresh the page for the tablet device.
  5. Select the Net tab on the Firebug panel.
  6. This panel will display all of the requests and files included on the page. This list should include the file master_tablet.css. You can filter this list to display only CSS files if desired. See Figure 2.
    Figure 2. The tablet CSS displayed in Firebug
    Screen capture showing all of the requests and files for the tablet CSS on the Firebug page
  7. Select a smartphone device from the User Agent Switcher extension in Firefox. See Figure 3.
    Figure 3. Selecting a smartphone device from user agent switcher
    Screen capture showing the drop-down selections for smartphones
  8. Refresh the page for the smartphone device.
  9. Select the Net tab on the Firebug panel.
  10. The list should include the file master_smartphone.css. See Figure 4.
    Figure 4. The tablet CSS displayed in Firebug
    Screen capture showing all of the requests and files for the smartphone CSS on the Firebug page

    Thus, based on the device that accesses the page, you can specify resources that are tailored for that device. You can also access these pages with the actual device, and you will see the theme optimized for that specific device and only the required resources. The default out-of-the-box theme for Portal 8.0.0.1 groups the styles into device-specific resources.


Using devices classes to filter dynamic content spots

Another new theme optimization mechanism introduced in Portal 8.0.0.1 is the ability to filter dynamic content spots based on device class. This enables you to control the markup that is rendered without adding additional logic within the JSP. Using this mechanism gives you a flexible approach for responsive design, where you can control markup directly in the template.

Add new dynamic content to the custom theme web application

To display the functionality of the filtering mechanism, we need to create new dynamic content to display for mobile devices. Adding a new JSP to your theme EAR is a simple process. The previous article in this series showed you how to create your own set of custom dynamic resources.

  1. Locate and copy the footer.jsp file of your custom theme at:

<wp_profile>\installedApps\<cell>\<CustomThemeEAR>.ear\<CustomTheme>.war\themes\html\dynamicSpots

  1. Paste the footer.jsp and rename the file to footer_mobile.jsp.
  2. Open footer_mobile.jsp, and at the top of the file, add a div element with text to signify that this is the mobile content. See Listing 5.
    Listing 5. Adding div element to footer_mobile.jsp
    <div>Footer mobile content</div>
    <%@ page session="false" buffer="none" %>
    <%@ page trimDirectiveWhitespaces="true" %>
    .
    .
    .
  3. If you do not have JSP reloading turned on, then restart the web application.

Update the theme template to filter dynamic content based on device classes

The next step is to update the theme template to use the new dynamic content for mobile devices. To do this, you will update the footer dynamic content spot to use the new POC URI mechanism and point to the footer_mobile.jsp.

  1. Open the theme template. For this article, we will use the localized template for English:
    fs-type1:themes/<customTheme>/nls/theme_en.html
  2. Locate the dynamic content spot for the footer. See Listing 6.
    Listing 6. The footer dynamic content spot
    <a rel="dynamic-content" href="dyn-cs:id:80theme_footer"></a>
  3. Replace the href value with a POC URI directly to the JSP. See Listing 7. The POC URI schema introduced in Portal 8.0.0.1 is mvc, which allows the device class filtering.
    Listing 7. The footer dynamic content spot with direct POC URI
    <a rel="dynamic-content" href=" mvc:res:/customTheme 
    /themes/html/dynamicSpots/footer.jsp"></a>
  4. After you place the URI into the dynamic content spot, persist the change back to webdav and load the theme in the browser. Ensure that after this change you can still load the theme and the footer is displayed. The footer will be displayed for all devices.
  5. Now introduce the device class filter by replacing the dynamic content spot URI with Listing 8. This URI has a default that will point to footer.jsp; tablet devices will point to footer_mobile.jsp; and smartphone devices will not display any content from this spot. This tablet content displays because using the mvc schema allows you to define an alternate POC URI specifically for a device class using the form <device class>@<poc uri>. Since a POC URI was not defined for smartphone, no content is rendered.
    Listing 8. The footer dynamic content spot with direct POC URI
    <a rel="dynamic-content" href=" 
    mvc:res:/customTheme/themes/html/dynamicSpots/footer.jsp,smartphone@,
    tablet@res:/customTheme/themes/html/dynamicSpots/footer_mobile.jsp"></a>
  6. After making the change to the theme template, you can now select a tablet device from the user agent switcher, and the text "Footer mobile content" will display in the footer area of the page. See Figure 5.
    Figure 5. Footer displayed on tablet device with new targeted dynamic content
    Screen capture showing all of the requests and files for the smartphone CSS on the Firebug page
  7. Change the user agent to a smartphone device, and notice that no footer content renders.
  8. Other sample URIs that can be tested within the footer content spot are shown in Listing 9 and Listing 10.
    Listing 9. Footer content spot with default URI and smartphone and tablet pointing to the same POC URI
    <a rel="dynamic-content" href=" 
    mvc:res:/customTheme/themes/html/dynamicSpots/footer.jsp,smartphone/tablet@
    res:/customTheme/themes/html/dynamicSpots/footer_mobile.jsp"></a>
    Listing 10. Footer content spot with content for smartphone and tablet and no default URI
    <a rel="dynamic-content" href=" 
    mvc:smartphone/tablet@res:/customTheme/themes/html/dynamicSpots/footer_mobile.jsp
    "></a>

The new URI schema for allowing multiple views based on device class creates a much more flexible framework when including dynamic markup for your web experience. For more information, see the Portal wiki topic "mvc:URI scheme."


Using device classes to filter page navigation

Sometimes your site design will include pages that are meant to appear only when accessed by a mobile device or only when accessed by a desktop browser. You can set these kinds of navigation filters by applying metadata to the Portal pages. Filtering by device class is turned off by default, but you can enable it by adding the content.topology.filter.deviceclass custom property to the WP ConfigService resource environment provider. For more information, see the Portal wiki topic "Filtering the content model."

Important: The filter is an opt-in model. Once filtering is turned on, any page that is NOT marked as supported by a particular class will not be shown. If no pages are marked as supporting a device class, this can lead to surprising results once filtering is on. For instance, if device class filtering is on, and pages are not marked as supporting "smartphone," a Portal page accessed with a smartphone will display something similar to Figure 6.

Figure 6. Page displayed with device class filtering enabled without support
Screen capture showing a page with no content defined

Note also that filtering is applied at each hierarchy level, and so each level must opt-in to be included in the navigation model.

Consider this portion of the sample content in Portal 8.0 displayed in Figure 7:

Figure 7. Portal 8.0 theme and pages
Screen capture showing Portal 8.0 theme and pages
  • ibm.portal.home (label)
    • ibm.portal.Home.Welcome (page)
    • ibm.portal.Home.Getting Started (page)
    • rwd.smartphone (page)
    • rwd.tablet (page)
  • ibm.portal.HiddenPages (label)
    • wps.Login (page)

If the "ibm.portal.home" label does not support the "smartphone" device class, none of the subpages will be shown, even if they are marked as supporting "smartphone.". Portal 8.0.0.1 defines the device class "smartphone" and "tablet," but other devices classes can be added to the system to fit your needs. For more information on creating and assigning device classes, see the Portal wiki topic "Device classes."

You can apply the supported device classes to the page using xmlaccess. Within the script, locate the device class that you want to set for the page(s) by using the <device-class /> element (see Listing 11).

Listing 11. Locating the device class within the xmlaccess script
<device-class action="locate" objectid="smartphone" 
uniquename="wps.deviceclass.smartphone"/>

After you locate the device class, you can then set support for that device class on the content nodes by using the <supported-deviceclass /> element (see Listing 12).

Listing 12. Setting device class support on a content node
<content-node action="update" uniquename="rwd.smartphone">
      <supported-deviceclass update="set" classref="smartphone" />
</content-node>

Listing 13 shows a full sample script that will add the "smartphone" device class to the "rwd.smartphone" page and the other required points in the hierarchy.

Listing 13. Sample xmlaccess script to apply smartphone device filtering
<request type="update" version="8.0.0.1" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:noNamespaceSchemaLocation="PortalConfig_8.0.0.xsd">
  <portal action="locate">
    <device-class action="locate" objectid="smartphone" 
  uniquename="wps.deviceclass.smartphone"/>
    <content-node action="update" uniquename="ibm.portal.Home">
      <supported-deviceclass update="set" classref="smartphone" />
    </content-node>
    <content-node action="update" uniquename="ibm.portal.Home.Welcome">
      <supported-deviceclass update="set" classref="smartphone" />
    </content-node>
    <content-node action="update" uniquename="ibm.portal.HiddenPages">
      <supported-deviceclass update="set" classref="smartphone" />
    </content-node>
    <content-node action="update" uniquename="wps.Login">
      <supported-deviceclass update="set" classref="smartphone" />
    </content-node>

    <content-node action="update" uniquename="rwd.smartphone">
      <supported-deviceclass update="set" classref="smartphone" />
    </content-node>
  </portal>
</request>

In the sample hierarchy mentioned above, this would yield a visible page structure for "smartphones" as displayed in Figure 8:

Figure 8. Page structure on a smartphone
Screen capture showing page structure on a smartphone
  • ibm.portal.home (label) opt-in "smartphone"
    • ibm.portal.Home.Welcome (page) opt-in "smartphone"
    • ibm.portal.Home.Getting Started (page) hidden from "smartphone" users
    • rwd.smartphone (page) opt-in "smartphone"
    • rwd.tablet (page) hidden from "smartphone" users
  • ibm.portal.HiddenPages (label) opt-in "smartphone"
    • wps.Login (page) opt-in "smartphone"

Listing 14 shows a similar sample script to apply the "tablet" device class to the site.

Listing 14. Sample xmlaccess script to apply tablet device filtering
<request type="update" version="8.0.0.1" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:noNamespaceSchemaLocation="PortalConfig_8.0.0.xsd">
  <portal action="locate">
    <device-class action="locate" objectid="tablet" 
uniquename="wps.deviceclass.tablet"/>
    <content-node action="update" uniquename="ibm.portal.Home">
      <supported-deviceclass update="set" classref="tablet" />
    </content-node>
    <content-node action="update" uniquename="ibm.portal.Home.Welcome">
      <supported-deviceclass update="set" classref="tablet" />
    </content-node>
    <content-node action="update" uniquename="ibm.portal.HiddenPages">
      <supported-deviceclass update="set" classref="tablet" />
    </content-node>
    <content-node action="update" uniquename="wps.Login">
      <supported-deviceclass update="set" classref="tablet" />
    </content-node>
    <content-node action="update" uniquename="rwd.tablet">
      <supported-deviceclass update="set" classref="tablet" />
    </content-node>
  </portal>
</request>

Again, in the sample hierarchy mentioned above, this would yield a visible page structure for "tablets" as displayed in Figure 9:

Figure 9. Page structure on a tablet
Screen capture showing Page structure on a tablet
  • ibm.portal.home (label) opt-in "tablet"
    • ibm.portal.Home.Welcome (page) opt-in "tablet"
    • ibm.portal.Home.Getting Started (page) hidden from "tablet" users
    • rwd.smartphone (page) hidden from "tablet" users
    • rwd.tablet (page) opt-in "tablet"
  • ibm.portal.HiddenPages (label) opt-in "tablet"
    • wps.Login (page) opt-in "tablet"

This <supported-deviceclass /> metadata element allows you to control your page structure on mobile devices based on device class.


Using content targeting (personalization) to filter page navigation

Starting with Portal 8.0.0.1, you can now use device class as part of your rule definitions to define page (or portlet) visibility. To do this, navigate to the "Manage Pages" area in the Portal administration. Find the page you want to include/exclude in your navigation, and edit the page properties. Under the Advanced section, define a visibility rule for the page. For more information, see the Portal wiki topics "Personalization and "Visibility Rules."

For these examples, we will use a page hierarchy like this:

  • Home (label)
    • Welcome (page)
    • Getting Started (page)
    • Targeting Desktop (page)
    • Targeting Smartphone (page)
    • Targeting Tablet (page)

For the "Targeting Smartphone" page, define a visibility rule named "Is Smartphone" (see Figure 10).

Figure 10. Visibility rule targeting smartphone devices
Screen capture showing visibility rule targeting smartphone devices

For the "Targeting Tablet" page, define a visibility rule named "Is Tablet" (see Figure 11).

Figure 11. Visibility rule targeting tablet devices
Screen capture showing visibility rule targeting tablet devices

For the "Targeting Desktop" page, define a visibility rule named "Is Desktop" that will display when the device is not a smartphone or tablet (see Figure 12). If you introduce more devices, you would need additional conditions.

Figure 12. Visibility rule targeting desktop devices
Screen capture showing visibility rule targeting desktop devices

Those rules are set for various pages to control visibility. For instance, on the "Targeting Smartphone" page, the "Is Smartphone" rule is applied as shown in Figure 13. You can apply the "Is Tablet" and "Is Desktop" rules appropriately for the other two pages.

Figure 13. Visibility rule is set for the "Targeting Smartphone" page
Screen capture showing that the visibility rule is set for the Targeting Smartphone page

Navigate to the Home label with a desktop browser, and it will look similar to Figure 14:

Figure 14. Desktop visibility rule is used to display page
Screen capture showing that the visibility rule is set for the Targeting Smartphone page
  • Home (label)
    • Welcome (page)
    • Getting Started (page)
    • Targeting Desktop (page) visibility rule "Is Desktop"
    • Targeting Smartphone (page) visibility rule "Is Smartphone"
    • Targeting Tablet (page) visibility rule "Is Tablet"

The same area looks like this when accessed with an iPhone device (see Figure 15).

Figure 15. Smartphone visibility rule is used to display page
Screen capture showing the Smartphone visibility rule being used to display page

And, again, the same area looks like this when accessed with a iPad device (see Figure 16).

Figure 16. Tablet visibility rule is used to display page
Screen capture showing the Tablet visibility rule being used to display page

One drawback is that anonymous pages do not support visibility rules. If the user is not logged in, and the pages in our example are visible to anonymous users, then all of the pages will be displayed (see Figure 17).

Figure 17. Anonymous pages do not work with visibility rules
Screen capture showing all visibility rules being used to display page

One more caution about mixing the two modes of filtering. As mentioned earlier, the navigation filtering is an opt-in model, and it takes precedence over the targeting rules. So, if you have added a targeting rule to your page to make it visible to "smartphones," you would still need to make sure that page has added opt-in for that device class. This can lead to confusing results, so it's best to use one filter or another but not both.


Summary

By using device class abstraction in WebSphere Portal to develop for a specific group of devices, you can optimize the design and performance of your user interface on mobile devices as well as personalize the site to show the best content to the right devices. This additional control will help improve customer satisfaction and deliver an exceptional responsive experience.


Download

DescriptionNameSize
Responsive design sample filesrwd2_sample_files.zip19KB

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=928589
ArticleTitle=Implement responsive web design using WebSphere Portal, Part 2: Using device classes to develop for specific devices
publish-date=05072013