Supportal

This is the first in a series of upcoming blog posts where we will delve into the details behind our Supportal.  As most of our customers are already aware, the Supportal is Jive's Clearspace customization that transforms generic communities into personal communities where Jive collaborates directly with our customers via cases, documents, and projects.

This first post will provide the high-level overview, overriding design goals, business goals, and additional benefits to the Supportal.  Future posts will delve into the business decision details, and the architecture.

The Name

People often ask how the name Supportal came to be.  When it comes to overall creativity, I am horrible.  In this project's infancy, I used Customer Portal, Customer Support Portal, Support Portal, and many other terms as names.   Will French, Jive's Senior Support Engineer, and now the Supportal Development Lead, abbreviated Support Portal, to Supportal (likely making fun of me talking too fast), and the name stuck.  It also gets rid of that stigma around the word "portal" as well!

Reasons for the Supportal

The Supportal was created to resolve's Support's own business pains.  Prior to identifying the business pains however, we set 3 main overriding goals for the project:

1. Simplicity: The goal of the supportal is to solve business pain.  Too many other support sites are tough to use and hard to navigate.  Creating a case needs to be as simple and easy as possible. We continue this philosophy on upcoming features, ensuring that additional features add benefit without causing pain.
2. Accessibility: Customers weren't getting the information they needed, and people within Jive were not seeing the information they needed.  The solution needed to include as many people as possible, while still being private so that only Jive and the customer can see the information.
3. Usability: Jive prides itself on this, and this is something that's always on our list.  Making the Supportal as usable as possible is also a guiding factor we focused on during the first iteration and continue to improve upon.

With the overriding goals set, we identified the following business goals:

• Create a solution where customers can go to create all their cases, regardless of severity
  
• Replace email with an online system as the mode of communication
  
• Recreate survey information.  Associate the survey to the case.
  
• Integrate Discussions (only community) with cases to provide customers with a single location to get their answer.
  
• Provide customers the ability to create public cases, allowing others (outside Jive support) to read, contribute, and resolve, while ensuring that Jive Support will answer your issue.
  
• Provide the same functionality (email) for customers who refuse to use the new system.
  
• Remove manual customer and contract validation process
  

Solution

With the business goals identified, we realized that we had to integrate with our online community.  Clearspace provided communities (security for each customer), email notification, reply by email, discussions, and a means to replace email as the primary mode of communication.  80% of the work was done for us.  The missing parts were:

• Auto-creation of customer communities via account, customer, and contract information in Salesforce
• Validating customer ability to create cases upon user login
  
• Adding meta data into customer community discussions, allowing them to become cases.
• Customizing customer communities to show cases instead of discussions.
• Synchronizing the cases (specifically the meta data) with Salesforce.
• Paging for Severity 1 cases
• Surveys
• Creating cases via email

The following blog posts are going to delve into these sections providing more information behind each business goal, and how we customized Clearspace to solve the goal.

Additional Benefits

As with many solutions, we quickly realized that the Supportal can be used for more than just customer cases.  The first additional use case for the Supportal was identified when our professional services team started using Clearspace's project functionality within the Secure Communities.  This was exactly what Clearspace Projects were intended for, and the Supportal solved our PS department's communication requirements perfectily with no additional customizations.

We also have experienced a slight decrease in overall cases due to the increased visibility of the cases.  Managers will frequently apply a community watch so that they receive emails whenever anyone creates a case in their community.  We have had managers reply to a case telling us to disregard the case due to it being something they need to solve internally.  We have also had managers follow up with their team directly when issues are stagnating, allowing us to resolve issues quicker.

Finally, the public case feature is being used for about 7% of all of our cases.  Not a huge number, but definitely significant, and each additional case that is made public results in additional information in our community for others to see and use.  This stat is without us pushing the feature at all.

Here are some resources for anyone wanting to migrate to Clearspace 2.0 or just learn more about the development environment for Clearspace 2.0.

A week ago, we did a series of presentations about Clearspace 2.0 development. We also videotaped all of the presentations, but the editing will take some time for the video, so I wanted to go ahead and share PDFs of the presentations now with the Jivespace community. The videos should be coming out at a rate of 1-2 per week over the next few weeks.

I have attached 5 presentations, and I suggest reading them in this order:

• Clearspace 2.0 Overview

• Theming

• Plugins

• Widgets

• Web Services

An easy way to extend Clearspace is by writing a macro. Macros can be used to modify and/or decorate a piece of a document, blog post or comment. For example: Say you wanted to include a map of downtown Portland, OR. Assuming you had the yahoomaps plugin installed, you could do so using the ymaps macro included in the plugin.

In a document or a blog post, you could write the following :

Jive Software is located in Downtown Portland
Address:
{ymaps}304 SW Adler, Portland, OR{ymaps}

When the document or the blog post is rendered, the

{ymaps}304 SW Adler, Portland, OR{ymaps}

portion of the document would be replaced by a map from Yahoo.

Writing a macro is simple, all you have to do is implement that Macro interface

public interface Macro{
    String render(String body, Map<String, String> parameters, MacroContext macroContext);
}

The return value (String) contains the HTML and/or Javascript code that replaces the macro tag in the document. For example, in case of Yahoo maps, the macro returns the following.

<script type="text/javascript" src="http://maps.yahooapis.com/v3.5/fl/javascript/apiloader.js?apid=foo"></script>
<div id="mapContainer_1234">
</div>
<script type="text/javascript">
...
</script>

When the document is rendered in the browser, the Javascript block executes and adds the Yahoo maps widget to the <div> element.

The render method of the Macro interface is passed three arguments.

• body: This argument contains the text between tags. So, 304 SW Adler, Portland, OR, would mean that the render method would be passed the string "304 SW Adler, Portland, OR" as the body argument.

• parameters: This argument is a map of name value pairs that capture the attributes set on the macro. For example, it is possible to specify the type of the map and zoom level by using "type" and "zoom" attributes on the yahoo maps plugin. So, 304 SW Adler, Portland, OR, will create a hybrid map with the zoom level set to 4. These two attributes will be passed inside the parameter map argument. In the code, you would access them using the name of the attribute as the key.

     String render(String body, Map<String, String> parameters, MacroContext macroContext){
          ....
          String mapType = parameters.get("type");//will return the string "hybrid"
          String zoomLevel = parameters.get("zoom"); //will return the string "4"
          ....
     }

• macroContext: macroContext argument allows you to get handle to objects and managers inside Clearspace. Most macros never use this argument, but sometimes it is neccesary call into Clearspace to lookup a value or peek at the document that the macro was included in. For example, the yahoo maps macro needs to ensure that yahoo apis javascript is included only once in a document, regardless of the number of times a macro was included in the document. So, in the render method, it queries the macroContext for the document body and checks to see how many times it has been included and appropriately includes the <script> tag when needed.

Testing

Unit testing macros is extremely easy, since all of the arguments of the render method are easily mock-able. Macros are ideal candidates for TDD, since you know exactly what the input arguments and the HTML/Javascript return value should look like.

Packaging and additional docs

Macros are packaged as part of a plugin. So, the process is the same as a plugin. See Plugin and Clearspace documentation for additional details.