Building Interactive Mobile Dashboards for the Salesforce Platform

In my previous post, I shared a sample application showing how to build highly interactive mobile dashboards using Web standards, D3 and other data visualization libraries.

In this post, I’ll share a similar application showing how to build interactive dashboards for the Salesforce platform using the Force.com APIs and the same charting libraries.

There are already many data visualization options either built into Salesforce or available on AppExchange. This sample application is just an exploration of the possibilities when adding interactivity and allowing the user to visually navigate through data using touch-based interactions (or mouse interactions when running on a traditional computer).

The Sample Application

Using the Force.com APIs, you can build interactive dashboards against any type of data in Salesforce. In this sample application, I chose to build some simple Sales dashboards around “opportunities”.

Watch a video:

Try it in your Browser

Click here to try the application in your browser.

This version of the application uses a static JSON file to make it easy to experience the application without a Salesforce account. The source code for the full version with the actual Salesforce integration is available below.

Data Visualization Libraries

Like I mentioned in my previous post, you can use a number of free (Flot, Flotr2, jqPlot, etc.) and commercial (amCharts, Highcharts, FusionCharts, ChartJS, etc.) data visualization libraries to build interactive dashboards. In the last couple of years, d3.js (D3) has emerged as a de-facto standard for data visualization. The D3 APIs are generally “lower level” compared to other libraries, but there are also libraries built on top of D3 (dimple, NVD3, xCharts, Rickshaw, …) if you are looking for higher level APIs. I used dimple for some of the charts in my D3 implementation.

I tried different libraries as part of my experiments, and I’ll share two implementations below: D3 and ChartJS. Again, this doesn’t mean that other options are not as good: I just didn’t have time to fully implement the dashboards with every single library.

Data Access Strategies

There are different options to retrieve data in your dashboards. You can use the traditional REST API, or the Analytics API (also implemented as a REST API).

Using the traditional REST API, your client application gets its data straight from standard or custom objects. Your are responsible for programmatically implementing the data selection logic in your application (using SOQL queries).

Using the Analytics API, you implement the data selection logic by building one or several Salesforce reports (Using the point-and-click report builder). In your application, you use the Analytics API to run these prebuilt reports and you get the data in JSON format. The analytics API offers additional features such as getting a list of reports, getting the metadata for a report, as well as the option to run reports synchronously or asynchronously.

In this simple example, I used the REST API to get a list of opportunities straight from the Opportunity object using SOQL. I plan to provide a similar example using the Analytics API in a future post.

Client-Side vs Server-Side Data Transformation

Different charts require the data to be filtered, grouped, and aggregated in different ways. So, another consideration is whether you process the data at the client side (in JavaScript) or at the server-side (using a series of custom SOQL queries or reports).

In the first option, you get a large data set from the server (for example, all the open opportunities), and the client application filters, groups, and aggregates the data as needed based on specific charts requirements as the user interacts with the dashboard. Limiting the number of network requests, and transforming the data at the client-side will generally deliver a more responsive user experience, but may become an issue if you are dealing with large data sets.

In the second option, the client application makes network requests to get the charts data filtered and aggregated based on specific charts requirements as the user interacts with the dashboard. Filtering, grouping, and aggregating the data at the server-side is a more predictable model, but the network latency involved in each request can make the dashboards feel less responsive.

Again, the right solution will depend on your specific situation and requirements, and a combination of these two options is usually a good approach. In this sample application with a small data set, I chose to make a single network request to retrieve the list of opportunities, and then transform the data at the client side.

Deployment Options

In this post, I share the application as a custom mobile app running outside the Salesforce container (browser or Salesforce1 app). But the exact same application could be deployed as a Visualforce page and delivered within the Salesforce container, in the browser or within the Salesforce1 application. I plan on covering these different deployment options in a future post.

Source Code

The source code for the ChartJS implementation is available in this GitHub repository.

The source code for the D3 implementation is available in this GitHub repository.

Running the Application on your Device

Follow the steps below to run the sample application (as a hybrid/Cordova app) in the iOS emulator or on an iOS device. Instructions to create a project using the Mobile SDK for Android are available here.

You’ll need a salesforce.com account to run this application. If you don’t already have one, you can sign up for a free developer environment here.
  1. Make sure Node.js is installed on your system. If it’s not, you can install it from here.
  2. Install the Force.com Mobile SDK for the platform of your choice (Android instructions are available here):
    sudo npm install -g forceios
    
  3. Create a new application
    forceios create

    Answer the prompts as follows (adjust the company id and organization name as needed):

    Enter your application type (native, hybrid_remote, or hybrid_local): hybrid_local
    Enter your application name: force-dashboard
    Enter the output directory for your app (defaults to the current directory): 
    Enter your company identifier (com.mycompany): org.coenraets
    Enter your organization name (Acme, Inc.): Coenraets, Inc.
    Enter your Connected App ID (defaults to the sample app’s ID): 
    Enter your Connected App Callback URI (defaults to the sample app’s URI): 
    
    · You can also provide these values as command line parameters when invoking forceios create. Type forceios on the command line and press return for a list of options.
    · For a real life application, provide a specific Connected App ID and Callback URI. Instructions for creating a connected app are available here or here.
  4. Delete the force-dashboard/www folder in the generated project folder.
  5. Click here to download the source code for the ChartJS implementation or here for the D3 implementation, then unzip the file anywhere on your file system.
  6. Copy the force-dashboard-chartjs/www or force-dashboard-d3/www folder from the unzipped file to the force-dashboard folder in your project folder.
  7. Open force-dashboard.xcodeproj in Xcode and run the application in the emulator, or on your device.
    To run the application on your device, you need an Apple developer certificate and an application provisioning profile.

Summary

I’m excited about the new possibilities around data visualization using web standards, and with the Force.com APIs, we have plenty of data to play around with and try new things. I’d love to hear and see what you are doing.

photo (3)

photo (4)

photo (1)

css.php