Introduction

If you're using the web to interact with customers, you're likely looking for ways to increase the satisfaction of your online users. Some common ways to increase user satisfaction are: increasing page responsiveness, producing intuitive and expressive interfaces, and creating a cohesive site layout. These are important to user satisfaction, but there are other things, such as communication and collaboration, that are worth considering. You can increase user satisfaction with your web site by enabling a more collaborative experience. Collaboration capabilities will let your users do such things as:

• Co-browse your site with other users
• Call a customer service representative with the click of a button embedded in a Web page
• Work directly with a customer service representative to ensure the accuracy and completeness of Web forms before submission

You can provide this type of collaboration capability using the WebSphere Application Server Communications Enabled Feature Pack. The feature pack includes Dojo widgets you can use to embed click-to-call, co-browsing, and two-way form capability. The use cases for these functions are nearly unlimited.

In this article, explore a scenario that implements three widgets that enable a customer service rep to help a user who is trying to complete and submit an online form.

Back to top

The scenario

Assume you're in charge of the web site for the fictional Acme Insurance Company. Acme wants to leverage the WebSphere Application Server CEA Feature Pack to quickly and effectively connect customer service reps with customers who are having problems filling out a new claim form.

This article guides you through the steps to create the solution using the WebSphere CEA Feature Pack. You will add the following capabilities to Acme's online claim creation process:

• Click a button on the new claim form to call a customer service rep.
• Click a button to start a session in which both the customer and customer service rep can view and interact with the claim form data.
• Automatically copy data from the claim form a customer started filling out to the one being co-browsed by the customer and customer service rep.
• Control what data can be seen and acted on when collaborating on a two-way form.

The next section looks at the initial claim creation form, and explains how to embed click-to-call capabilities directly on that form.

Back to top

Adding click-to-call capability

For this scenario you will work from an existing form, claimform.html, which your customers use to submit new claims online.

At this point, the form is very basic. Customers log in, complete the required claim information, and submit it to Acme for processing by clicking Submit Claim.

Suppose one of your customers has a question while filling out the claim form. Perhaps they forgot their policy number, or they want to know exactly what to include in the claim amount. Right now, they'd have to stop working online, look up the number to call for assistance, and then place the call. The customer has to spend time on those tasks, and might even have to start the claim creation process all over again. This could lead to customer dissatisfaction and ultimately be a detriment to customer retention. It would be easier, and save time, if the customer could place a call to a customer service rep without leaving the claim creation form.

This scenario is perfect for the WebSphere CEA ClickToCall widget. You can embed the widget directly on the claimform.html page, thus allowing users to place a call to your customer service reps without leaving the page or stopping the claim creation process.

You need to make two small modifications to the HTML code. First, add the necessary import statements to import the JavaScript and CSS files provided by the WebSphere CEA Feature Pack for the ClickToCall widget, as shown in Listing 1.

                
<script type="text/javascript" src="ceadojo/dojo/dojo.js"
  djconfig="parseOnLoad: true, isDebug: false">
</script>
                
<style type="text/css">
      @import "ceadojo/dijit/themes/tundra/tundra.css";
      @import "ceadojo/dojo/resources/dojo.css";
      @import "ceadojo/cea/widget/ClickToCall/ClickToCall.css";
</style>

<script>
   ceadojo.require("dijit.form.TextBox");
   ceadojo.require("dijit.form.SimpleTextarea");

</script>

After the necessary CSS and JavaScript files are included, add the ClickToCall widget by adding another row in the form table with the HTML code in Listing 2.

<tr>
   <td>
      <div ceadojoType="cea.widget.ClickToCall"      
           widgetNumber="sip:CSR@localhost">
      </div>
   </td>
</tr>

The example in Listing 2 declares the ClickToCall widget in the div element, and declares the destination Session Initiation Protocol (SIP) URI in the widgetNumber attribute as CSR@localhost. Adding the HTML and JavaScript code in Listings 1 and 2 updates the claimform.html page, as shown in Figure 2.

Now a user can initiate contact with a customer service rep by entering their number and clicking Call Me. The phone indicated by the SIP URI in the widgetNumber attribute of the ClickToCall widget will be notified and will place a call to the number entered by the user.

Back to top

Adding co-browsing and a two-way form

Consider the situation where a user started filling out a claim form but could not locate their policy number. They could call a customer service rep using the new ClickToCall widget. After verifying the customer's identity, the rep could look up and relay the policy number to the user. It's simpler than it would have been before the ClickToCall widget, but it's still not ideal. The customer service rep has to read a long policy number over the phone, and the user has to listen and type that number into the form field. During this information relay there's a margin for error; the wrong data could end up in the policy number field.

It would be a much better experience if the user and customer service rep could jointly browse and interact with the new claim creation form. Then, the customer service rep could provide assistance directly in the HTML form and the information exchange does not take place over the phone. You can achieve this very thing with a few additional widgets.

The first step is to enable the ClickToCall widget, which you already embedded on the claimform.html page, to support co-browsing capabilities. You also need to update the CSS imports on the claimform.html page, as shown in Listing 3.

<style type="text/css">
    @import "ceadojo/dijit/themes/tundra/tundra.css";
    @import "ceadojo/dojo/resources/dojo.css";
    @import "ceadojo/cea/widget/ClickToCall/ClickToCall.css";
	@import "ceadojo/cea/widget/Cobrowse/Cobrowse.css";
	@import "ceadojo/cea/widget/CollaborationDialog/CollaborationDialog.css";
</style>

<script>
   ceadojo.require("dijit.form.TextBox");
   ceadojo.require("dijit.form.SimpleTextarea");
</script>
            

At this point, you add three new attributes to the existing ClickToCall widget declaration, as shown in Listing 4.

<tr>
   <td>
      <div ceadojoType="cea.widget.ClickToCall"      
           widgetNumber="sip:CSR@localhost" 
           enableCollaboration="true"  
           canControlCollaboration="true"           
           defaultCollaborationUri="collabform.html">
      </div>
   </td>
</tr>

The enableCollaboration attribute set to true indicates to include co-browsing capabilities as part of the ClickToCall widget. The canControlCollaboration attribute set to true means that the customer can control the co-browsing capabilities if the customer service rep chooses to give them control. Finally, the defaultCollaborationUri attribute value indicates the initial page that will be loaded in the co-browsing session.

Before discussing the collabform.html page, there's something important to know about using the ClickToCall widget in conjunction with co-browsing capabilities. To start a co-browsing session with the customer, a page accessible by the customer service rep must have a way to listen for incoming calls and initiate such sessions. The CEA Feature Pack's CallNotification widget provides this capability.

A separate page, csrhome.html, with the CallNotification widget listens for calls from the customer and provides the capability to co-browse the claim creation form with the customer. Similar to the widgets used previously, Listing 5 shows how to import the necessary CSS files.

<script type="text/javascript" src="ceadojo/dojo/dojo.js"
	djconfig="parseOnLoad: true, isDebug: false">
</script>

<style type="text/css">
      @import "ceadojo/dijit/themes/tundra/tundra.css";
      @import "ceadojo/cea/widget/CallNotification/CallNotification.css";
      @import "ceadojo/cea/widget/Cobrowse/Cobrowse.css";
      @import "ceadojo/cea/widget/CollaborationDialog/CollaborationDialog.css";
</style>
            

With the imports in place, you declare a CallNotification widget within a table on the page, as shown in Listing 6.

<table cellspacing="25" cellpadding="25" class="formContent">
   <tr><th style="font-weight:bold;font-size:large">Acme Insurance Claim 
        Hotline
       </th>
   </tr>
   <tr>
      <td><div ceadojoType="cea.widget.CallNotification" 
               widgetNumber="sip:CSR@localhost"   
               enableCollaboration="true" 
               canControlCollaboration="true" 
               defaultCollaborationUri="collabform.html"></div>
      </td>
   </tr>
</table>
            

The CallNotification widget attributes are identical to those of the ClickToCall widget on the claimform.html page. In this case, the widgetNumber attribute value indicates the number at which the widget will listen for calls. Incoming calls to the sip:CSR@localhost phone, which occur when a customer uses the ClickToCall widget, result in the notification of this CallNotification widget. Again, the necessary collaboration attributes are defined, and the defaultCollaborationUri is set to the same value as is set in the ClickToCall widget on the claimform.html page. The new csrhome.html page should now display the widget, as shown in Figure 3.

Before starting the CallNotification widget so that it's actively listening for incoming calls, you need to create the collabform.html page that both the ClickToCall and CallNotification widgets reference in their defaultCollaborationUri attributes.

The new collabform.html page will contain a form that is a field-by-field copy of the original form on the original claimform.html page. On the new page, instead of using a regular HTML form you'll use the TwoWayForm widget. Again, the first step is to import the necessary CSS and JavaScript files for the page.

<script type="text/javascript" src="ceadojo/dojo/dojo.js"
	djconfig="parseOnLoad: true, isDebug: false"></script>

<style type="text/css">
      @import "ceadojo/dijit/themes/tundra/tundra.css";
      @import "ceadojo/dojo/resources/dojo.css";
      @import "ceadojo/cea/widget/TwoWayForm/TwoWayForm.css";
</style>

<script>
   ceadojo.require("dijit.form.TextBox");
   ceadojo.require("dijit.form.SimpleTextarea");
</script>
            

Copy the HTML in the body section of the claimform.html page into the body section of the collabform.html page. Alter the form element and specify a ceadojoType attribute with a value of cea.widget.TwoWayForm, as shown in Listing 8.

<form id="claimReqForm" ceadojoType="cea.widget.TwoWayForm"  
      style="background-color:rgb(223,223,223)">	
            

Other than that small change, the only change to make to the copied HTML is to remove the ClickToCall widget. For this example, though, it won't be necessary because we'll only use this particular page in the context of a co-browsing session. If you were to view the collabform.html page, you'd see exactly the same output as shown in Figure 1.

You're almost ready to test the initial calling and co-browsing flow for the claim request form. Before doing so, you need to configure the necessary telephony components to conduct the application testing. For this example, you can get instructions from the Info Center for the CEA Feature Pack. The example in this article registers one phone at sip:CSR@localhost and the other at sip:Customer@localhost.

Back to top

Testing co-browsing capability

After the telephony infrastructure is in place, you load the csrhome.html page and activate the CallNotification widget by clicking the Start call notification icon. As shown in Figure 4, the status changes to indicate the CallNotification widget is available and waiting for incoming calls.

The example opens a separate browser. (The CEA Feature Pack uses cookies to store session state, so it must be a separate browser—not a separate window in the same browser.) The next step is to open the claimform.html page. Assume the user starts the claim creation process by entering a name, but then decides they need help. They enter sip:Customer@localhost as the customer's number and click Call Me. This initiates a call to the sip:CSR@localhost phone, which, when answered, initiates a call back to the sip:Customer@localhost phone. When the phones connect you see an update to the ClickToCall widget's status on the claimform.html page, as shown in Figure 5.

Open the csrhome.html page and you'll see a similar update to the status for the CallNotifcation widget, as shown in Figure 6.

To start the co-browsing sessions, click the co-browse icon on both the ClickToCall and CallNotification widgets. In each browser, a modal window opens and the collabform.html page appears in the pane.

To begin the session, the customer service rep, who opened the co-browsing session from the CallNotification widget, has control of the session. You can test the two-way form capabilities by entering a value in the Policy number field in the customer service rep's window. You should see the same value show up in the same field of the customer's co-browsing session.

Now that the policy number is correct, the customer can go back to entering the claim data. As shown in Figure 8, the data entered by the customer shows up highlighted in the customer service rep's window. The two users can simultaneously collaborate on the data in the form without having to grant control back and forth.

Back to top

Preserving confidentiality in a two-way form

Many online forms contain confidential information, such as a social security number, a credit card number, or a home address. You might create a two-way form that contains data to which only one user in the interaction should be privy. In the example claim creation form, to maintain privacy it's probably not wise for the customer service rep to see the name of the other party in the accident. You can use two special attributes for elements in the TwoWayForm widget to ensure that only the customer can supply and read the name of the other party in the accident.

Open the collabform.html page in an HTML editor and locate the input field for the field labeled "Name of other party." You can see the original declaration in Listing 9.

<input type="text" ceadojoType="dijit.form.TextBox" id="otherName"   
           name="otherName"></input>	
            

To ensure that only the customer can edit the value of this input element and the masking of the value in the customer service rep's window, use the ceaCollabWriteAccess and ceaCollabFilter attributes.

<input type="text" ceaCollabWriteAccess="reader" 
       ceaCollabFilter="default" ceadojoType="dijit.form.TextBox" 
       id="otherName" name="otherName"></input>
            

Setting the ceaCollabWriteAccess attribute to reader indicates only the reader in the session can edit the value of the input element. In this case, the customer is the reader. The customer service rep, who initiated the session, is the writer. The default value in the ceaCollabFilter attribute causes the masking of the input value in the window of the writer (in this case, the customer service rep). Figure 9 shows the result.

The default value of the ceaCollabFilter attribute indicates that you want to use the default masking function, which, as shown in Figure 9, replaces the content of the input element with a string of * characters. If needed, you could supply your own custom masking function. To do that, you'd specify the name of a function as the value of the ceaCollabFilter attribute. This function accepts a string as an argument (the original value of the field), and returns a masked version of the value.

Back to top

Transferring data to the co-browsing forms

Suppose a customer encounters a problem after they've started filling in data on the claim creation form. They then solicit help, using click-to-call and co-browsing, from a customer service rep. As it works now, form data entered by the user on the claimform.html page will not automatically transfer to the form on the collabform.html page at the start of the co-browsing session. The customer would have to re-enter information on the claim form in the co-browsing session. Obviously, this is a significant inconvenience. Luckily, you can avoid inconvenience to your users by extending the behavior of a couple of the widgets to make sure information is copied from the original claim creation form over to the two-way form in the co-browsing session.

To provide the function needed to copy over form data at the beginning of a claim creation co-browsing session:

1. Create a new module.

   Create a new folder structure to hold the extended artifacts in the application.

2. Modify the ClickToCall widget template.

   Modify the template of the ClickToCall widget to include an attribute that indicates the name of the form from which to copy elements.

3. Modify the ClickToCall widget's JavaScript

   Modify the JavaScript of the widget to reflect its new package name and to refer to the new CollaborationDialog widget.

   Provide function to gather all the form elements, and their values, on the claimform.html page and make these available to the CollaborationDialog widget.

4. Modify the CollaborationDialog widget's JavaScript.

   Add a function to set the value of the elements for the claim creation form on the collabform.html page in both the customer and customer service rep's co-browsing session. The values come from the elements copied and passed to the CollaborationDialog widget by the extended ClickToCall widget.

5. Update the claimform.html page.

   Update the claimform.html page to use the newly extended widgets.

Creating a new module

First, you want to extend the ClickToCall widget to gather all of the elements and their values from the form on the claimform.html page. Create a new folder structure within the application, and copy to it the three JavaScript files you are modifying:

• ceadojo/cea/widget/CollaborationDialog.js
• ceadojo/cea/widget/ClickToCall.js
• ceadojo/cea/widget/ClickToCall/ClickToCall.html

The new folder structure has a root folder of acme, and the subdirectory layout mocks that of the cea module provided by the WebSphere CEA Feature Pack. See Figure 10.

Modifying the ClickToCall widget template

In the interest of maximum reuse and flexibility, you want to declare the name of the source form (the form from which you will copy elements) in the HTML declaration of the ClickToCall widget. Add the sourceForm attribute to the ClickToCall widget's template and make the value of that available to the ClickToCall widget. In the ceadojo/acme/widget/ClickToCall/ClickToCall.html file you will see an element whose dojoAttachPoint is collaborationDialog. The element contains attribute definitions, such as enableCollaboration and canControlCollaboration, which are available to both the ClickToCall and CollaborationDialog widget. Add the new sourceForm attribute, as shown in Listing 11.

<div
    dojoAttachPoint="collaborationDialog" 

    dojoType="acme.widget.CollaborationDialog"
    sourceForm="${sourceForm}" 

    canControlCollaboration="${canControlCollaboration}" 

    defaultCollaborationUri="${defaultCollaborationUri}" 

    highlightElementList="${highlightElementList}" 

    isHighlightableCallback="${isHighlightableCallback}" 

    isClickableCallback="${isClickableCallback}" 

    sendPageUrlRewriteCallback="${sendPageUrlRewriteCallback}">

</div> 
            

In addition to defining the new sourceFrom attribute, notice that the code also changed the dojoType to refer to the acme.widget.CollaborationDialog widget. This will be the name of the extended CollaborationDialog widget when you're done with the modifications, so go ahead and make the update now to ensure the extended ClickToCall widget leverages the new functions. These are the only two changes you need to make to the ClickToCall widget's template. The next step is to modify the JavaScript for the widget.

Modifying the ClickToCall widget JavaScript

In the source of the ceadojo/acme/widget/ClickToCall.js you'll change the declaration statements and a require statement. Update the declarations to declare acme.widget.ClickToCall in place of cea.widget.ClickToCall, and update the require statement for the CollaborationDialog to reference acme.widget.CollaborationDialog, as shown in Listing 12.

dojo.provide("acme.widget.ClickToCall");
dojo.require("acme.widget.CollaborationDialog");
dojo.declare("acme.widget.ClickToCall", [ cea.widget.ClickToCall ],
            

In the dojo.declare statement, the example changes the base widget value to cea.widget.ClickToCall. You can remove many of the other require statements because you're extending from this base widget.

You need to make some changes to the variables in the ClickToCall JavaScript source. The goal is to make sure the new widget is pointing to the modified template you created in the previous step. Add a variable for the sourceForm attribute.

dojo.declare("acme.widget.ClickToCall", [ cea.widget.ClickToCall ],
{
   templateString : null,
   templatePath: dojo.moduleUrl("acme.widget",               
                                "ClickToCall/ClickToCall.html"),
   sourceForm: "",

To point to the new template, set the templateString value to null and declare a templatePath variable that refers to the modified HTML template file. The code also creates a sourceForm variable to hold the value of the sourceForm attribute you defined in the new template.

The final modifications to ClickToCall widget's source are to gather the elements from the specified form and make them available to the CollaborationDialog widget instance. Add a new function called getSourceFormElements to retrieve the elements from the form indicated by the sourceForm attribute, and set them on the CollaborationDialog widget instance. After that, modify the ClickToCall widget's existing cobrowse function to call this new function. The complete source for the newly extended ClickToCall widget is shown in Listing 14.

dojo.provide("acme.widget.ClickToCall");
dojo.require("acme.widget.CollaborationDialog");
dojo.declare("acme.widget.ClickToCall", [ cea.widget.ClickToCall ],
	{
		templateString : null,
		templatePath: dojo.moduleUrl("acme.widget", 
                "ClickToCall/ClickToCall.html"),
		sourceForm: "",
		getSourceFormElements : function() {
	         var sourceFormObj = dojo.byId(this.sourceForm);
		   this.collaborationDialog.sourceFormElements = 
               sourceFormObj.elements;
	      },
		cobrowse : function() {
	         this.getSourceFormElements();
		   this.collaborationDialog.openCollaborationDialog();
		}
       }
);

The rest of the function declarations are removed because you can simply inherit them from the base cea.widget.ClickToCall widget.

Modifying the CollaborationDialog widget JavaScript

After you've completed the modifications to the ClickToCall widget, you can make the necessary changes to the JavaScript of the CollaborationDialog widget. As with the extended ClickToCall widget above, start by making changes to the declaration and variables section of the source. Modify the name of the widget you are declaring to be acme.widget.CollaborationDialog, and change the base widget list to simply contain cea.widget.CollaborationDialog.

Declare the sourceFormElements and sourceForm variables. The extended ClickToCall widget references the sourceFormElements; you'll use the sourceForm variable later. As with the CallNotification widget, the initial value of the sourceForm variable comes from the value of the sourceForm attribute when a user declares the ClickToCall widget using HTML.

                
dojo.provide("acme.widget.CollaborationDialog");
dojo.declare("acme.widget.CollaborationDialog",           
[cea.widget.CollaborationDialog ],
{
sourceFormElements : null,
sourceForm : “”,
            

Add a new method called setTargetFormElements that contains the logic to copy the values from the original form on the claimform.html page to the two-way form on the collabform.html.

setTargetFormElements : function() {
   dojo.withDoc(this.collaborationDialogContentPane.domNode.contentWindow.document, 
      function() {
         if(this.sourceFormElements != null) {
            var matchedCount = 0;
	        for(ct=0; ct < this.sourceFormElements.length; ct++) {
		var sourceElement = this.sourceFormElements[ct];
		var currElement = dojo.byId(sourceElement.id);
		if(currElement != null) {
		    if(currElement.options && sourceElement.options) {
			for(optCt=0; optCt < sourceElement.options.length; optCt++) {
			    if(sourceElement.options[optCt].selected) {
			        currElement.options[optCt].selected = true;
				window.top._ceaTwoWayForm._widgetHandlers
				[currElement.id]._changedByUser = true;
				window.top._ceaTwoWayForm._widgetHandlers
				[currElement.id]._handleOnChange(currElement.value);
				matchedCount++;
				break;
			    }
			}
		     }
		     else if(sourceElement.value != ""){
		        console.log(sourceElement);
			currElement.value = sourceElement.value;
			window.top._ceaTwoWayForm._widgetHandlers[currElement.id].
			_changedByUser = true;
			window.top._ceaTwoWayForm._widgetHandlers[currElement.id].
			_handleOnChange(currElement.value);
										
		     }
		 }
	  }
	}
    }, this);
},
            

The setTargetFormElements makes use of the dojo.withDoc function to be able to interact with the DOM contained in the window of the co-browsing session. Hence, the function in the example is able to interact with elements on the collabform.html page. The setTargetFormElements function loops over all the elements in the sourceFormElements array and, for each one, attempts to find an element on the current document (the collabform.html page) with a matching ID. After it finds the appropriate value, the code triggers a change event using the widget handlers for the TwoWayForm widget instance.

All you need to do now is make sure to call the new function before the form appears in the customer's co-browsing session. You can insert a call in the existing openCollaborationDialog function, as shown in Listing 17.

openCollaborationDialog : function() {
   this.setTargetFormElements();
   this.inherited(arguments);
}

The other methods are removed, because the extended widget inherits them from the cea.widget.CollaborationDialog base widget.

Make updates to the claimform.html page to include the new ClickToCall widget and, by association, the new CollaborationDialog widget. This is achieved by simply updating the dojo require statements and CSS imports, as shown in Listing 18.

 <style type="text/css">

    @import "ceadojo/dijit/themes/tundra/tundra.css";
 
    @import "ceadojo/dojo/resources/dojo.css";
 
    @import "ceadojo/cea/widget/ClickToCall/ClickToCall.css";
 
    @import "ceadojo/cea/widget/Cobrowse/Cobrowse.css";
 
    @import "ceadojo/cea/widget/CollaborationDialog/CollaborationDialog.css";
 
           </style>

     
 <script>

    ceadojo.registerModulePath("acme","../acme");

    ceadojo.require("dijit.form.TextBox");

    ceadojo.require("dijit.form.SimpleTextarea");

    ceadojo.require("dijit.form.ComboBox");

    ceadojo.require("acme.widget.ClickToCall");
 </script>
            

After you package these changes and redeploy the application, you can verify the new function. Starting on the claimform.html page, enter a claimant name, accident date and time, police report number, and a few more bits of information, as shown in Figure 11.

Assume that you need help from a customer service rep at this point, so you click the Call button. After you're connected, the rep decides it would be best to enter a co-browsing session to solve the problem. When the co-browsing window is opened, you see that the information you entered on the claimform.html page automatically transfers to the collabform.html page in the co-browsing session.

Because the code in Listing 16 manually fires the onChange event, the information from the initial form transfers to both the customer and customer service rep's co-browsing window with no additional modifications.

Back to top

Summary

The Dojo widgets of the WebSphere CEA Feature Pack provide the capability to significantly enhance the communication and collaboration capabilities of your online applications. Right out of the box, you can embed these widgets in your existing and new applications to enable click-to-call, co-browsing, and two-way form interactions. If the out-of-the-box functions don't quite provide what you need, you can use Dojo basics for the customization functions your application requires. Check out the WebSphere CEA Feature Pack if you think your Web applications can benefit from enhanced communication and collaboration.

Back to top

Download

Information about download methods

Resources

Learn

• The Feature Pack for Communications Enabled Applications, Version 1.0.0 Info Center provides all necessary documentation.
  
  
• The IBM Redbook Getting Started with the WebSphere Application Server Feature Pack for Communications Enabled Applications V1.0 provides information about the architecture and implementation of the features in the IBM WebSphere Application Server Feature Pack for Communications Enabled Applications, V1.0 (referred to as the CEA feature pack).
  
  
• Read the Official Dojo Documentation, including information on what's new, getting started, and reference guides.
  
  
• Check out the videos at IBMcea Channel on YouTube.
  
  
• Visit the developerWorks Open source zone for extensive how-to information, tools, and project updates to help you develop with open source technologies and use them with IBM's products, as well as our most popular articles and tutorials.
  
  

Get products and technologies

• Download the WebSphere Application Server V7 Feature Pack for CEA.
  
  
• Innovate your next open source development project with IBM trial software, available for download or on DVD.
  
  

Discuss

• Find other developerWorks members interested in Web development.
  
  
• Participate in the WebSphere Application Server forum.
  
  
• Read the blog Communications Enabled Applications.
  
  
• Create your My developerWorks profile today and set up a watchlist on WebSphere Application Server. Get connected and stay connected with My developerWorks.
  
  
• Find other developerWorks members interested in Web development.
  
  
• Web developers, share your experience and knowledge in the Web development group.
  
  
• Share what you know: Join one of our developerWorks groups focused on Web topics.
  
  
• Follow developerWorks' members' shared bookmarks on Web topics.
  
  

About the authors

Dustin Amrhein joined IBM as a member of the development team for WebSphere Application Server. While in that position, Dustin worked on the development of Web services infrastructure and Web services programming models. In addition, Dustin lead the technical effort in the development of a Java RESTful services framework. In his current role, Dustin is a technical evangelist for emerging technologies in IBM’s WebSphere portfolio. His current focus is on WebSphere technologies that deliver cloud computing capabilities, including the WebSphere CloudBurst Appliance.

Andy is an IBM advisory software engineer and architect for the Communications Enabled Applications Feature Pack. He received a Bachelor of Science degree in computer engineering from Pennsylvania State University in December 2002 and joined IBM in January 2003.

Rate this article

Comments

Back to top

Table of contents

• Introduction
• Scenario
• Adding click-to-call capability
• Adding co-browsing and a two-way form
• Testing co-browsing capability
• Confidentiality
• Transferring data to the co-browsing forms
• Summary
• Download
• Resources
• About the authors
• Comments

Next steps from IBM

• Try: WebSphere Application Server
• Briefing: Building SOA solutions and managing the service lifecycle
• Buy: WebSphere Application Server

Dig deeper into Web development on developerWorks

IBM SmartCloud trial. No charge.

Unleash the power of hybrid cloud computing today!

---

Public and private solutions in one trial.

Special offers