As a Power BI consultant I use many custom visuals from the AppSource marketplace and have tested many more, if not most of them. The good news is that there are some excellent visuals in there. The bad news is that quality and usefulness is all over the place, and there are quite a few unmaintained visuals that haven’t seen any love since their publication 2-3 years ago.
I should start by thanking these publishers who contribute their visuals for free. Thus the following unsolicited feedback and guidance will hopefully be received as constructive:
- Support as many Power BI features as possible so that your visual really feels native rather than a foreign graft. There are many visuals that don’t support things such as report tooltips, hierarchies, cross-filtering/highlighting (in and out of your visual), or expression-based formatting. I understand some of these features are newer, or not even fully implemented by Microsoft themselves across default visuals. I’m just describing what’s ideal here.
- Refrain from redoing Power BI features in a different way just because you can. This reduces discoverability, especially if your visual doesn’t have affordances similar to Power BI itself. Right-clicking is not for options in Power BI, there’s a side panel for that! Don’t implement sorting in your own way unless you’re going beyond PBI, for instance to support multi-column sorting, which Excel does but PBI doesn’t in its default visuals.
- Stick to the same default font typefaces and sizes for menus within your visual’s titles and axes. Otherwise the visual will feel out of place, and possibly amateurish and jarring against everything else on the canvas.
- Be active and responsive in the AppSource comment section as well as in Github – for open source visuals – or some sort of user forum otherwise.
- Make sure you use user-friendly labels, and don’t hesitate to complement them with tooltips. Many of the KPI-focused visuals could do a better job in this area.
- Provide an example with a proper star schema, not just a single flat table. Nobody worth their salt is using, say, dates from fact tables as opposed to a separate calendar dimension. Having a realistic example will speed up use in real-world projects rather than just quick proofs of concept.
- Get your visual certified, which among other things will enable export to PPT/PDF via the Power BI service.
The underlying principles to these suggestions are the following:
- Commit to keeping up with Power BI improvements and changes, whether from the perspective of the Power BI Desktop UI, or in terms of the custom visual SDK. I know, this is significant work.
- Choose the right publication vehicle. It’s great if your visual is just a labor of love, meaning that you may not commit to SDK updates, support, bug fixes and whatnot. But then should you bother publishing it on AppSource, which is in itself a nontrivial endeavor? My expectation as a developer is that AppSource visuals should be ready for production use in corporate scenarios. This is not currently the case. There’s always the option to install from a file, so consider just offering your visual as a download.
- Make the UI/UX as tightly integrated and consistent with Power BI itself. Don’t reinvent the wheel, and don’t make me learn yet another tool unless that’s absolutely necessary. Bear in mind that your visual will not work in a vacuum, but in conjunction with many other visuals (some of them also of the custom sort) on the same page and across report pages or even reports.
AppSource risks becoming a bit like WordPress or mobile app marketplaces where you’re drowing in options but none of them really work well. In the case of WordPress, many plugins and themes in effect try to rebuild WordPress within WordPress, with many themes behaving as horribly clunky mini-CMSes instead of sticking to presentation. There’s always a tension between quantity and quality, and while it’s great to have options, there’s a cost to having to sort through them and find what’s working.
Granted, the first wave of custom Power BI visuals from 2017 is probably worse in that regard and obviously, this is also where abandonware syndrome is more of an issue. But at about 220 visuals things are already starting to get cluttered. Obviously that’s an issue for Microsoft to manage but everyone should act responsibly in how they contribute to the pool, or whether they should at all.
I’m not sure whether publishers can voluntarily unpublish from AppSource [*], but if that’s possible maybe some of them should do that if their visual is effectively discontinued. Don’t get me wrong, I’m not judging as I myself abandoned a bunch of projects and websites over the years.
[*] Update: the esteemed David Eldersveld confirms that publishers can unpublish their visual, which he just did with his R DataTable. Unfortunately Microsoft just 404s the page rather than keeping a landing page with some explanation about the discontinuation. The visual continues to “live” on Github, where you can see that there are 11 open issues, as well as David’s warning that “R DataTable is provided “as-is” with no direct developer support. If you find an issue with the visual, please log it here on GitHub. Please note that logging an issue is no guarantee that your issue will be resolved.”
As Microsoft finally embraced open source after years of denial under Steve Ballmer, the company will have to deal with well-known OSS sustainability concerns affecting their ecosystem. Of course abandonware is even more of a problem with commercial software with Google being the worst offender there.
Meanwhile, for these authors that my entry might jolt into updating their visual, you’ll want to check out Daniel Marsh-Patrick’s blog for examples and tips.