What I learnt building Power BI Custom Visuals

[Chamara]

Data visualization plays a pivotal role today more than ever before in providing actionable insights. With large volumes of data at our disposal and more continuously generated, it is becoming ever more challenging to make sense of data without visualizations. At times, I wonder whether it’s time to debunk the idiom “a picture is worth a thousand words” as “thousand” is no longer representative in today’s context.

Microsoft Power BI has taken some innovative steps to truly democratize data visualization. One of which is to provide a platform for 3rd parties to contribute custom visuals.  Custom visuals play an important role today across the BI Ecosystem, Community and for Business Intelligence advancement in the following ways:

• Eye-catching - enticing, recognizable, informative &, contextual
• Engaging - to view and spend time exploring data, soaking up information and discovering insights
• Building sense and intelligence loyalty - senses include visual, analytical and other vectors
• Enriching the visualization palette – empower mere mortals to become artists that light-up data-driven scenarios; tools to create visual incarnations of beauty
• Self-Actualizing data – compared with other art forms, information visualization is still at a comparatively nascent phase; take learnings from nature and inspire knowledge and wisdom with creations of beauty

I started building a custom visual few months back to fill up a gap observed during a data visualization project.  You can find this visual named Tachometer in Power BI Visuals Gallery.

Figure 1. Different configurations of Tachometer custom visual.

I also joined hands with a great team at Annik (now LiquidHub) with blessings from the Microsoft Power BI team to drive a Hackathon like program internally named Annik Power BI Challenge to inspire and create new custom visuals that would be published to the visuals gallery in the future.  

Here I would like to reflect on some of the best practices and experiences along the way for the benefit of anyone building a Power BI custom visual.

1.         Share your learnings

The Power BI Community is all about sharing and building on that shared knowledge. Building custom visuals would have been extremely difficult for new entrants if not for the open source code provided by the Power BI Team and other custom visual developers. Give back to the community by sharing your learnings and your source code.

2.         Start with something that is already available

With many visuals available in the Power BI Visuals Gallery, it is likely that someone has already built similar functionality you want to have in your visual. Existing visuals help provide a starting point and a basic structure to build your custom code upon. For example, I started building Tachometer using Microsoft gauge visual code as a sample. When completed, the Tachometer code hardly had anything common with gauge visual code. However, the gauge visual helped to get things moving faster.

3.         Default settings

Custom visuals come with default settings. Some of these are customizable through capability settings. Make the default settings applicable for the most common application of your visual, so that the user who is adding your visual to a report can readily apply it with minimal modifications.

For example, Tachometer visual spans from -120 degrees from vertical to +120 degrees and has green, yellow, red regions in that order by default all of which can be customized for each of your instances.

4.         Enable customization

Users of your visual want the freedom to be creative with many aspects of their reports. This includes the capability to customize the look and feel of your visual in their reports such as changing colors and font sizes. When creating your visual try to expose as many features as you can through configurable capability settings.

Some capabilities may be tough to implement, but when done right, will add value to your visual and appeal to a wider audience. For example, when I saw different gauge visuals such as the "gauge" which span 180 degrees and "circular gauge" which spans 360 degrees, I thought why not combine the two by making the angle configurable. This simple idea led to configurable angles for the Tachometer. Although enabling customizations doubled the code base, this feature replaces the need to have an infinite number of visuals each with a slightly different start and end angle combination for an example. 

5.         Socialize your idea

If you are a developer (as many of you probably are having read this far), there may be some non-technical aspects you may miss such as business uses, aesthetic appeal, etc. Socialize your visual among a wider and diverse audience early, get their inputs and feedback, incorporate them.

6.         Create a Video

If your visual is not trivial and easily understood, a video description of the visual will be helpful for end users. Demonstrate the most common features and usage of your visual. A real-life scenario that can be easily understood by many without specific subject matter expertise is ideal if used to describe the usage of your visual (ex., Tachometer Video).  

The video should ideally be 3 minutes to keep the audience engaged, and try not to make it longer than 5 minutes. If required, make two videos: one with the basic/common functionality and a second with additional details that can supplement documentation of your visual.

7.         Create good user documentation

Document your visual. Add plenty of screenshots and diagrams to help users understand the context and applications. Have the documentation reviewed by someone not familiar with your visual to make sure it is understood by a first-time user. “Markdown” is a quick, easy, and common format used for documentation. See an example here: Tachometer Documentation

8.         Strive for quality code

With the popularity of open source solutions, people put in a greater effort to write quality code.  This is no exception when it comes to Power BI. If you have a close look at the iterations that Power BI visuals have gone through, especially those published by Microsoft, you will notice improvements in code quality. Be it simple things like having meaningful names for your variables (eg. "min" renamed as "minDate" in lineDotChart code), structure of the code (eg. breaking draw() into drawline() and drawDots() in lineDotChart), or introducing support to patterns like "DataViewObjectsParser".

With transition from web based Power BI Dev Tools to CLI tools, we can see code being structured into modules and helper classes.

We still have some way to go with our Tachometer visual and we are working towards them.

9.         Prioritize Performance

Keep performance a top priority. It may not have a significant impact if your visual works with a very small data set and even less for visuals that work with aggregated data sets such as gauges. Alternatively, some visuals may involve processing larger sets of records that necessitate more focus on performance.

If your visual performs repetitive calculations with the same data values, then explore the possibility of making these calculations up front and storing the results in your data model to be reused. We have a relatively bloated data model in Tachometer and with good cause.

10.       Get your code reviewed

"Looks good" has become the most common code review feedback we get these days surpassing "I am not familiar with this technology".  I prefer seeing a genuine code review with issues noted down including references, something that we took pride in at some of my past engagements. Code reviews not only help improve code, they also help learning and adopting coding best practices. Seek review from someone who would spend the time and provide as much feedback as possible. It does not take much time really, to go over a couple thousand lines of code in a custom visual and write a helpful review.

11.       Test your code

Make sure you test your visual on all common browsers and Power BI desktop. Depending on how complex your visual is, there can be discrepancies. You can automate some unit testing using Karma and Jasmin or other similar technologies. Make use of them.

12.       Report issues

While developing our custom visuals, we encountered gaps in Power BI documentation. These were fixed within days of us reporting them. Some of the more demanding gaps took longer like visual utilities.

Depending on where the issue is, you can report them through "issues" or the appropriate forum. Consider doing this as returning a favor to the Power BI community.

13.       Do not underestimate the Power BI Visual publication process

The power BI Visual publication process is not automated. Surprised? Once you submit your visual, it gets tested manually. Publishers of Custom Visuals know very well how involved this process can be.

When we made our initial submission of Tachometer custom visual, we knew of some limitations it had but we were eager in getting it published on the Visuals Gallery (a pretty common scenario in product development) and planned to release updates later. That did not work to our favor. These limitations were caught and sent back our way to fix. Microsoft Power BI Team tests your visual thoroughly. Kudos to them.

Well, to summarize, think about the end user, get all the help you can, strive for quality and test thoroughly.

Good luck creating compelling custom visuals!