Add file transfer capabilities to the CollaborationDialog

The CollaborationDialog widget in the WAS CEA feature pack provides capability that is leveraged during cobrowsing sessions. Part of the function in the widget consists of sending data between the participants in a cobrowse session. This enables function like highlighting, following, and sending a page. It's this, the capability to send data back and forth between participants, that can be leveraged to produce very useful extensions to the base CollaborationDialog widget.

Take for example the previous scenario I blogged about. In that case, a few extensions to some of the CEA widgets provided an enhanced, online communications experience between a customer and an insurance company customer service representative. What if during the course of that communication the policy was updated and the customer service representative wanted to send the new policy to the customer? Well, it could be sent via email and the customer could check it at some later time. However, a simple extension to the CollaborationDialog widget to provide file transfer capabilities will allow the customer service representative to send and the customer to receive the updated policy right away.

To do this we can leverage the CollaborationDialog widget's existing ability to send data back and forth between cobrowse participants. Your first thought may be that we actually use the data sending capability to directly send file contents back and forth, but that's not what the data sending infrastructure was designed for. Rather, it was designed to send small, chatty messages. With that in mind, we use simple AJAX functionality to post a form containing a file attachment to a backend file server. Then, we leverage the data sending infrastructure to notify the other cobrowse participant that they are being sent a file, and we provide the location of that file so it can be downloaded.

We also make some changes to the HTML and CSS files for the CollaborationDialog, and combined with the necessary JavaScript additions mentioned above, we can now choose and send files as seen below:

We can also receive files from our cobrowsing partner:

The capability to send and receive files while in a cobrowse session can significantly enhance the experience of both participants. If you are interested in how you can add this extension into your WAS CEA environment, drop a comment right here and we'll be happy to set you up with some examples.

Extending the Cobrowse widget

I'm still looking at and experimenting with the WebSphere CEA Feature Pack widgets. In my last two posts I took a look at scenarios that lead to extending the WebSphere CEA ClickToCall widget. In my latest project, I took a look at the Cobrowse and CollaborationDialog widgets.

It's clear that there are many scenarios where users would want to employ and maybe even extend these two widgets. For instance, check out the demonstration below for one such scenario.



There are a few things to note about the sample as far as the extensions go. First of all, I did a very simple extension to the ClickToCall widget along the same lines of my previous posts, so I won't go into much detail about that particular piece.

Other than the ClickToCall extension, I extended both the Cobrowse (cea.widget.Cobrowse) and CollaborationDialog (cea.widget.CollaborationDialog) widgets to provide the function you see in the sample. With the Cobrowse widget, I added functionality such that when the customer service representative creates the collaboration link, a resource representing that link and the customer it is intended for is created on the backend. That was easy to do by overriding the Cobrowse widget's _convertToWaitingState method and providing custom function to create the necessary resource.

When a customer logs into the Insurance Company's home page, JavaScript running on the page checks the backend for any resources that would indicate a customer service representative has invited that particular customer to a collaboration session. In the sample video, this is shown when the customers logs into the Insurance Company's site.

Next, I needed to extend the CollaborationDialog widget in a couple of ways. First, I added the Send Policy Data button to the dialog's toolbar. All that was required to add the button was a small update to the widget's JavaScript. No HTML or CSS changes were necessary.

After that, I added a function that allows the customer service representative to send the retrieved policy information from his window to the customer's window. This was done by piggy-backing on the ability of the CollaborationDialog widget to send data back and forth between the collaboration participants. There was a nifty Dojo function that came into play when implementing this capability. Once the data was received by the CollaborationDialog instance on the customer side, the contents of the content pane in the CollaborationDialog needed to be updated. This was done by using dojo.withDoc as seen below:

dojo.withDoc(iframeDoc,
function() {
          var data = this.receivedPolicyData;
          dojo.style(dojo.byId("policyTable"), "display", "block");
          dojo.byId("policyNumText").innerHTML = data['policyNum'];
          dojo.byId("policyHolderText").innerHTML = data['policyHolder'];
          dojo.byId("policyTypeText").innerHTML = data['policyType'];
          dojo.byId("policyAmountText").innerHTML = data['policyAmount'];
          dojo.byId("policyPremiumText").innerHTML = data['policyPremium'];
          dojo.byId("policyPaymentScheduleText").innerHTML =                                                   
                     data['policyPaymentSchedule'];
          dojo.byId("policyDeductibleText").innerHTML =
                     data['policyDeductible'];
          },
          this
);

The dojo.withDoc method allowed me to update the DOM of the source HTML page for the content pane, and in this case it was extremely helpful.

The required changes to implement these widget extensions were fairly minimal considering the capabilities that were added. In fact, the backend data services for the various resources used by this sample took most of my time. If you are interested in seeing more of the code for the sample above just drop a reply to this blog post. I'd be happy to share more of the extension implementation.

More use cases for CEA widget extension

Just a few days ago I documented my first example with extending the WebSphere CEA click-to-call widget to provide a customized experience between a customer and customer service representative.That experience opened my eyes to the tons of use cases for extending the click-to-call widget (or any of the WebSphere CEA widgets for that matter).

For instance, a growing trend among restaurants is to offer food ordering online. You can go online, place your order, and either have it delivered or pick it up at some later time. So, I thought about the employee back at the restaurant monitoring these orders, and in particular I thought about how they may benefit from embedding communication capabilities in that online ordering system.

Consider my fictional pizza company, The Acme Pizza Company, and the back-end to their online ordering system. The employee back at the restaurant may view a list of the pizza orders and confirm each of those orders for the kitchen team.

When the restaurant employee clicks the Confirm Order it is probably necessary to show more information about the order and the customer who placed the order. But wouldn't it also be nice to allow the restaurant employee to simply click a button to call the customer that placed the order when it was necessary?

An easy extension to the WebSphere CEA click-to-call widget gives us both the information about the order and the embedded communication capabilities that allow the restaurant employee to connect with the customer directly from the web page.

The panel you see above is a simple dijit.Dialog widget that contains an extended version of the cea.widget.ClickToCall widget. The Acme Pizza Company employee has all the information they need to confirm the order, and they can even call the customer directly from the web page if necessary.

The possibilities for extending the WebSphere CEA widgets are endless. I hope to post more scenarios of interest involving different widgets soon. In the meantime, if you're interested in the JavaScript and HTML involved in building up this extension, you can download it here.

Extending WebSphere CEA widgets

Since it’s my first time posting here, I guess a quick introduction is in order. My name is Dustin Amrhein and I’m a technical evangelist for emerging technologies (cool stuff) in WebSphere. I do not work on the WebSphere CEA development team, but I have been experimenting with the new CEA Feature Pack for the WebSphere Application Server lately.

The first thing I did after installing the CEA Feature Pack was install and play around with the PlantsByWebSphere sample application that is included in the install. The cool features provided by the CEA Feature Pack, like co-browse, click-to-call, and call notification immediately jump out through the sample.

With the introduction to some of the features of the CEA Feature Pack behind me, I decided to peek under the covers a bit. In particular, I was interested in the Dojo widgets that provided the interface to the functionality on display. If you are familiar with Dojo, you’re well aware that one of the benefits of Dojo widgets is that they can be easily extended to deliver custom function and interfaces. With that in mind, I decided to look into extending one of the widgets delivered by the CEA Feature Pack, the click-to-call widget.

If you look at the Contact Us page of the PlantsByWebSphere, you will see an example of the click-to-call widget:

Suppose I wanted to extend this widget just a bit. I want to give my users the option to select from a list of specialist in the different areas of my site (flowers, trees, vegetables, accessories), and once they select a particular specialist I'd like to display information about the person with whom they will be in contact. After all, it's always nice to know who's on the other end!

To do this, I first start by extending the provided cea.widget.ClickToCall JavaScript:

dojo.provide("extension.ClickToCall");
dojo.require('cea.widget.ClickToCall');

dojo.declare("extension.ClickToCall", [ dijit._Widget, dijit._Templated,
  cea.widget.ClickToCall ], {

templatePath : dojo.moduleUrl('extension', 'ClickToCall/ClickToCall.html'),
templateString : "",

handleSpecialistSelect : function(item) {
 var url = "/proxy/bpp?specialist=" + item;
 var responseHandler = dojo.hitch(this, "handleContactResponse");
 var errorHandler = dojo.hitch(this, "handleContactError");
 dojo.xhrGet( {
    url : url,
  handleAs : "json",
  timeout : 5000,
  load : responseHandler,
  error : errorHandler
 });
},

handleContactResponse : function(response, ioargs) {
 this.returnedInfoRow.style.display = "block";
 this.callInfoRow.style.display = "block";
 this.contactInfoFromGet.innerHTML = "Click the Call Me button to be contacted
    by " + response['firstName'] + " " + response['lastName'] + " in "
  + response['city'] + ". Alternatively you may email "
  + response['firstName'] + " at " + response['email'] + ".";
  this.widgetNumber = response['phone'];
},

handleContactError : function(response, ioargs) {
 console.error("error getting contact info " + response + " status " +
    ioArgs.xhr.status);
}
});

The above contains the dojo declaration of my custom widget that extends the existing cea.widget.ClickToCall. The handleSpecialistSelect above will send an HTTP GET request when a user selects the particular type of specialist with whom they wish to talk. In my case, the GET request is sent to an Ajax proxy that then forwards the request for contact information along to the appropriate service. This allows us to use data in our JavaScript that is provided by a service in a different domain. The handleContactResponse populates the page with the contact information returned from the GET request.

The JavaScript above also references a new HTML template via the templatePath variable. The new template can be seen here:

<div>
<table class="clickToCallWidget">
  <tr id="contactInfoRow">
     <td>
        <table>
           <tr dojoAttachPoint="getContactRow">
              <td>I want to contact a  
               <select
                   dojoType="dijit.form.ComboBox"
                   dojoAttachEvent="onChange:handleSpecialistSelect" id="specialist"
                   name="specialist">
                   <option value="none">-- Make Selection --</option>
                   <option value="flowers">Flowers Specialist</option>
                   <option value="trees">Trees Specialist</option>
                   <option value="vegetables">Vegetables Specialist</option>
                   <option value="accessories">Accessories Specialist</option>
               </select></td>
           </tr>
           <tr dojoAttachPoint="returnedInfoRow" style="display: hidden">
              <td><span dojoAttachPoint="contactInfoFromGet"></span></td>
           </tr>
        </table>
      </td>
   </tr>
   <tr dojoAttachPoint="callInfoRow" style="display: none">
      <td>
         <table dojoAttachPoint="callInfoTable">
            <tr>
               <td><label dojoAttachPoint="phoneNumberLabel"
                  title="${myNumberString}"><input name="phoneNumber"
                  dojoType="dijit.form.TextBox" dojoAttachPoint="phoneNumber"
                  class="clickToCallWidgetTextBox" value="${myNumberString}"></input></label>
               </td>
               <td>
                  <button dojoType="dijit.form.Button" dojoAttachEvent="onClick:call"
                   dojoAttachPoint="callButton"
                   iconClass="clickToCallWidgetIcon clickToCallWidgetCallIcon"
                   class="clickToCallWidgetButton">${callButtonString}
                  </button>
               </td>
               <td>
                  <button dojoType="dijit.form.Button"
                   dojoAttachEvent="onClick:hangup" dojoAttachPoint="hangupButton"
                   iconClass="clickToCallWidgetIcon clickToCallWidgetEndCallIcon"
                   class="clickToCallWidgetButton" style="display: none">${hangupButtonString}
                  </button>
               </td>
               <td>
                  <button dojoType="dijit.form.Button"
                   dojoAttachEvent="onClick:cobrowse" dojoAttachPoint="cobrowseButton"
                   iconClass="clickToCallWidgetIcon clickToCallWidgetCollaborateIcon"
                   class="clickToCallWidgetButton" style="display: none">${cobrowseButtonString}
                  </button>
               </td>

            </tr>
            <tr>
               <td colspan="4" dojoAttachPoint="status" class="clickToCallWidgetStatus" style="display: none">
               </td>
            </tr>
         </table>
      </td>
   </tr>
</table>
<div dojoAttachPoint="collaborationDialog"
   dojoType="cea.widget.CollaborationDialog"
   canControlCollaboration="${canControlCollaboration}"
   defaultCollaborationUri="${defaultCollaborationUri}"
   highlightElementList="${highlightElementList}"
   isHighlightableCallback="${isHighlightableCallback}"
   isClickableCallback="${isClickableCallback}">
</div>
</div>

To get my extended click-to-call widget in the PlantsByWebSphere sample application I need to do a couple of things. First I need to add my new files to the application. I'll add them in the PlantsByWebSphere.war file within the PlantsByWebSphere.ear. Relative to the root of the WAR file, I'm adding the following:

• /ceadojo/cea/extension/ClickToCall.js (JavaScript file above)


• /ceadojo/cea/extension/ClickToCall/ClickToCall.html (HTML above)

I'm also going to modify the contactus.html at the root level of the PlantsByWebSphere.war to use my custom widget instead of the normal one. To accomplish this, I first add the following to the HTML head section:

<script type="text/javascript">
 ceadojo.registerModulePath("extension","../cea/extension");
 ceadojo.require("extension.ClickToCall");
 ceadojo.require("dojo.parser");
</script>

After that is taken care of, I change the value of the ceadojoType attribute. Before it referenced the cea.widget.ClickToCall widget shipped with the CEA Feature Pack. As seen below, I change the ceadojoType attribute's value to extension.ClickToCall.

<TD>

<h2>Click To Call</h2>

<div id="clickToCallWidget">

<!-- Replace 'CSR@localhost' with the user and address to be contacted when a clickToCall call is initiated -->

<div ceadojoType="extension.ClickToCall" widgetNumber="sip:CSR@localhost" enableCollaboration="true"

canControlCollaboration="true" defaultCollaborationUri="index.html">

</div>

</TD>

Now I'm ready to test out my changes. When I visit the contactus.html page, I'm greeted by a different view:

Once I select a particular specialist I want to contact, I then see information about the person who will be contacting me:


This is just one example of how the widgets provided by the WebSphere CEA Feature Pack can be extended to deliver customized function and behavior. I hope this helps give you a glimpse into the basic pattern for customizing the WebSphere CEA widgets. By the way, you can download a PDF of the JavaScript and HTML displayed above here.

Retailers need WebSphere CEA

There have been so many times lately that I have been realizing that websites need the WebSphere CEA features and functions. Recently my wife was shopping online and trying to send me links and describe over instant messaging what she was seeing. It was painful and we finally decided we would hold off until later that evening. We forgot that night and looked again at it a day later. That was a sale that was almost lost. Actually, to be honest, the sale was lost...but had we had peer to peer cobrowsing on that site we may have purchased it that first day.

I have also had the experience many times when buying gifts where I knew nothing about the subject matter and had to call a company or visit their store. Whether it was custom jewelry I bought my wife for mother's day or shopping for something for my own mother, there are times I just need more information than I can find online.

After talking to a major US retail company the past couple of days it became evident that our CEA functions when shown were much more amazing. This is why I made the video above, to show this typical experience I have when shopping for something and I need help. But the ability to shop with a friend brings a whole new experience to online shopping and could help drive another boost to online commerce sites. Below I have shown a video describing how that interaction might work.

There are other major areas when seeing something online would be useful when on the phone. For example, last year it was apparent our credit card info was stolen and had to call into Chase and describe the transactions that were invalid. We could have saved time if I could have shown them which transactions through a couple of clicks rather than describing them. But security is a constraint...can you show your customer information without security? How about without a plugin? The CEA FEP does this with security, using the application's current security model. There is no plugin, its all Javascript. It requires some new thinking - but not necessarily new code. :-) We'll talk more about secure cobrowsing soon...

Web communications enhancing interactions

One of the common questions as people are learning about our WebSphere Communications Enabled Applications (CEA) function is if we are trying to replace interactions with "real people" when they see features such as the cobrowsing. The real idea behind CEA is using an interactions via the web to enhance real time communications which could be phone calls or instant messaging. There are several scenarios that we try to show in the demo video below, but here are some of the common issues that a web based interaction could solve in a contact center:

Click to Call:

• Increase efficiency by removing the need for people to type in phone numbers they see on a web site.
  
• Help a user connect to the most relevant help based on what page they are on without having to traverse a voice based menu system.
  
• Provide the backend contact center with relevant user information from their web session.
  

Contact Center Cobrowsing

• Help explain complex data to customers which may be too difficult to describe. Some examples include mortgage closing costs, insurance policy details, order information, financial transaction details, or product information. Customers could print or save the information which could result in them not having to transcribe what the contact center representative is saying.
  
• Teach a customer how to use a specific site rather than just telling them an answer so that they may not need to call again for a similar issue.
  

Two way forms

• Allows a customer to visually verify information rather than waiting for the contact center representative to repeat it. For example, a misspelled last name can take time, cause problems looking up information in the future, and decrease customer satisfaction. Two way forms allows the customer to visually verify what the contact center representative has entered.
  
• Either party in the session could fill out some fields which, if it makes more sense for the customer to do it, can increase efficiency.
  
• Some vital data like Social Security Numbers or Account/Credit Card numbers could be entered by the customer and obfuscated to the contact center representative reducing the risk of critical information being misused.
  

All of these scenarios are in the context of a real time communications session like a phone call. Here is a demo we have shown in the past showing these features in a contact center scenario. Download the beta now from the link on the right hand column and try the application shown below yourself.

Contact Center Demo of CEA function

Here is another homemade demonstration of the WebSphere Application Server Communications Enabled Applications function in a Contact Center environment. Here we have our call notification widget, click to call widget, and contact center cobrowsing functionality embedded in our Plants by WebSphere sample application.



Savio wrote more about how these Contact Center scenarios can play out here. Also, the widgets have some further detail here in a blog I wrote. Finally, if you are at IBM Impact this week, check out our 10:30 AM Session in Murano 3205 entitled "Lower Costs, Improve Satisfaction with Communications-Enabled Applications." And, more importantly, ask us questions while there!

Peer to Peer cobrowsing in retail makes for a real coshopping experience?

A couple of days ago, Savio wrote more about utilizing our peer to peer cobrowsing functionality. Today at Impact 2009, we demonstrated WebSphere Commerce utilizing the peer to peer cobrowsing widget to allow for a coshopping environment. In this, Daisy Tan extended the cobrowsing functionality to add instant messaging into a Commerce deployment so that users of that could cobrowse and instant message with one another in the cobrowsing modal window. Perhaps I will get a demo of that integration up later, but for now here is a homemade video of the peer to peer cobrowsing with the sample provided in the feature pack. This shows a simple scenario for coshopping within the application. Our demonstration could have been just as easily a travel planning application, insurance benefits application, or any number of applications allowing two people to view a similar page and use the web as another communication modality. Check it out and let us know what you think! (aside from the fact that I am obviously not a professional voiceover guy or video editor ;-) )

Your applications need a dose of CEA - Peer to Peer Scenario

In my previous post I mentioned that the WAS V7 Feature Pack for CEA Beta can help you create some pretty awesome user experiences for multi-modal online interactions. Well, what does that really mean? I've already covered the Contact Center scenario. Now, let's discuss a Peer to Peer scenario.

Your loyal customers, Savio and Hilary, always use your travel planning website to decide on itineraries and book travel.

Savio is away at IMPACT for a week. This leaves Hilary alone with their two month old. Erik, Savio's wise friend suggests Savio take Hilary on a vacation as a "thanks for putting up with me and rearing our child while I travel". Hilary loves to be involved in vacation planning. But Savio's in Vegas and Hilary's in Toronto (See P.S. below). Savio IM's Hilary and proposes the vacation idea. She's in. Now the tough part. Deciding where, which flight, hotel and car. It's made tougher by the fact that their multi-modal interaction is not linked in any way.

If Savio and Hilary continue the interaction over IM, they're forced to send URLs back and forth to keep track of the itinerary item that the other person is looking at. But then, they'd also have to type "flight #348 will get us in on time" and similar information into the IM application. But switching over from IM to the phone is no better because they still have to describe which page each person is on, (spelling out a URL over the phone...FUN!?!?), and which flight they are looking at etc. Savio and Hilary are in for a poor user interaction no matter how you slice it.

We designed the WAS V7 Feature Pack for CEA Beta to address a scenario of two users trying to jointly make a decision through a multi-modal interaction.

Peer to Peer Cobrowsing
Let's start the same scenario off with a Peer to Peer Cobrowsing Web Widget that is delivered in the WAS V7 Feature Pack for CEA Beta. Savio would click on the "Invitation Link" button on your website and IM it to Hilary. Once Hilary clicks the link, Savio and Hilary would be in a shared session together. There's not software for Savio or Hilary to install to enable this shared session. In fact, Savio and Hilary have individual sessions with WebSphere Application Server, so there's an added layer of security. Calling this feature Peer to WebSphere Application Server to Peer, while perfectly okay with the IBM Naming Police, seemed cumbersome. Ease of use and security? Check.

With this shared session both Savio & Hilary can take control and direct what is shown on the other person's browser window. Both can highlight elements on the page for the other person to see. Vastly improved user experience? Check.

And of course, if either needs more information before deciding, they could use the Click to Call feature enabled by the WAS V7 Feature Pack for CEA and enter into a joint session with one of your customer service representatives. I described this scenario before.

Want to learn more?
Get the WAS V7 Feature Pack for CEA Beta here and the Getting Started guide, part of the Library materials, here. Also, here's a good description of the widgets from Erik. Finally, if you need a copy of WAS V7, you can get a trial here.

Let us know what you think!

P.S.: Hilary and I planned our last trip sitting beside each other, with our individual laptops scouring Expedia for info. It was painful to keep track of the itinerary item that the other person was suggesting. So, while the scenario above describes two geographically separated users, I'm certain it'll apply to two users sitting beside each other on a couch! What that says for our society is a different story ;-)

Your applications need a dose of CEA - Contact Center Scenario

In my previous post I mentioned that the WAS V7 Feature Pack for CEA Beta can help you create some pretty awesome user experiences for multi-modal online interactions. Well, what does that really mean? Let's start with a common scenario.

While searching for a life insurance policy online a user might want to call a customer service representative (CSR) about discounts since her mortgage is held by the bank. More often than naught, the CSR wants to point the user to more information on the bank's website. But here's the dilemma. The user and CSR are involved in a multi-modal interaction, but there's no synchronization between the two modes of communication. If the CSR wants to direct the user to a specific page on the site, he must tell the user "okay, go to the homepage, on the left navigation bar, click Other Offers and then scroll half way down the page, look for a link that says...." Agreed, that's an ugly interaction.

When the user decides to purchase life insurance, the interaction is no prettier. While the user and CSR are speaking on the phone and both have browser windows open, there is no linkage between the two modes of communication. The user still has to speak certain information which the CSR must transcribe into the application form. There's no visual way for the user to verify that the CSR has transcribed the spoken information properly. Try saying "Savio Rodrigues" and the person on the other end of the phone not transcribe "Fabio Rodriguez" or "Flavio Rodriguez" or "Sabio Rodriguez". Not cool.

We designed the WAS V7 Feature Pack for CEA Beta to address a scenario in which a user and CSR are involved in a multi-modal interaction prior to the user making a decision.

Click to Call
Let's consider the same scenario with a Click to Call Web Widget that you can embed in existing and new web applications.

Unlike third party hosted Click to Call offerings, the Click to Call feature in the WAS V7 Feature Pack for CEA Beta can be completely integrated into your application. No need to spawn another browser window or advertise your hosted provider's service. Integrated and consistent user experience? Check.

Next, our Web Widget is integrated with your telephony infrastructure (so far, Cisco & Nortel). Why pay a third party Click to Call hosted provider per minute fees for calls when you can leverage your existing telephony infrastructure? Lower costs and driving higher utilization of existing resources? Check.

Finally, any information that you want to share between the user and the CSR through the Click to Call session, such as login information or account numbers, does not have to go through a third party. Increased privacy & security? Check.

Contact Center Cobrowsing
Okay, you added a Click to Call widget to your application, now what? Well, your customer enters her phone number and clicks on "Connect". The result is a shared session between the user and the CSR (through WebSphere Application Server). Oh, and there is no software for the user or CSR to install. Security and ease of use? Check.

With this shared session both the CSR and the user can take control and direct what is shown on the other person's browser window. Both can highlight elements on the page for the other person to see. No more having to say "scroll half way down the page and look for the link to the right of the picture of a monkey". Improved user experience? Check.

Two Way Forms
Next up, the dreaded filling out of forms over the phone. But have no fear. Since you have a shared session between the user and CSR, there's no reason that the form can't be displayed to both parties. But why stop there? The Two Way Forms feature of the WAS V7 Feature Pack for CEA Beta lets both parties enter data into various elements of the form. You can even restrict the data shown in a form field between the CSR and user. For example, the user could type in and see their full credit card or social security number, while the CSR would only see the last 3 digits. The user can even click to confirm that individual form field data was transcribed correctly by the CSR. Fewer frustrated users? Check.

Want to learn more?
Get the WAS V7 Feature Pack for CEA Beta here and the Getting Started guide, part of the Library materials, here. Also, here's a good description of the widgets from Erik. Finally, if you need a copy of WAS V7, you can get a trial here.

Let us know what you think!

Your applications need a dose of CEA

As Erik posted on Friday, the IBM WebSphere Application Server V7.0 Feature Pack for Communications Enabled Applications Beta (WAS V7 Feature Pack for CEA Beta) is now live.

Why should developers care?

Skills Reuse, Improved User Experiences & Lower Costs:
Well, with your existing Java skills, the WAS V7 Feature Pack for CEA Beta can help you create some pretty awesome user experiences that improve the effectiveness of multi-modal online interactions and reduce costs. The WAS V7 Feature Pack for CEA Beta targets scenarios where users are interacting with each other through multiple modes of communications.

We've all been on a website, or for that matter, any web-based application, trying to find the right information before making a (purchase) decision. Often, multiple modes of communications (i.e. phone & website; instant messaging & website, etc.) are needed to obtain the information and make the decision.

Over the next two posts (here & here) I'll discuss two key scenarios where the WAS V7 Feature Pack for CEA Beta shines. Saddle up...