Dealing with desktop-based content creation

from Google image search results for "desktop bi content creation" from microsoft.com

Disclaimer: I hope this post ages poorly.
 
Desktop-based development was once the norm in wave 2 BI platforms, and it was something we did not question in the olden QlikView days. Yet it persists in Power BI and to a lesser extent Tableau. Building on your local machine can be good for some things, but there are reasons why platforms are adding more support for web-based content authoring and some things you can do in the meantime to mitigate the downsides.

Relevance of desktop content creation, by platform

  • A meaningful pain point with Power BI is the inability to create Datasets on the web. You can create the front end on the web, but the back end must be created with Power BI Desktop. This also creates some weird situations, like being unable to upload but not download a Dataset with incremental refresh from the service to subsequently modify it, in addition to the cons listed below. Power Query already works on the web in various forms, from Azure Analysis Services to Power BI Dataflows, so it doesn't seem like a big stretch to just build Power BI Datasets there. With Microsoft's continuous improvements, my hope is that this limitation will go away at some point. 
  • Qlik Sense has led with web-based authoring since day 1, but there are some quirks to its relationship with file systems. You often generate, read, and sometimes must edit or delete files organized in folders somewhere, the latter of which cannot be done over the web. In Qlik SaaS editing files is not supported and finding the mechanism to delete them is difficult as of now (buried in the load script editing interface). There is a Desktop version of Qlik Sense, as well, but it's probably used more by consultants like me than people in regular deployments.
  • Tableau generally supports anything on the web that you can do in the desktop (including Tableau Prep), at this point, yet developers still exhibit a strong preference for desktop-based development in my experience. Maybe they're all handy with Tableau keyboard shortcuts?
  • ThoughtSpot is web-everything down to the data sources, which can also be limiting. Personal BI is not something it seeks to do.

Benefits of desktop-based content creation

  • Personal BI, i.e., visualizing or creating solutions with local, one-off files for personal consumption. With Qlik and Power BI, users may also have more latitude to create net new content without an added licensing cost than they do on the server, even though they may lack the rights to share/publish them. This also shields the server of processing overload from their missteps :)
  • Review and pick apart community examples of technical solutions to see how they are built without having to import them onto the server first.
  • When using local or cached data, you can work entirely offline with desktop versions of platforms.
  • For Tableau and Power BI, you can interact and prototype with published datasets, hosted online, with a low workload on your machine.
  • If you don't have a true "dev" environment, the desktop can function as a development environment of sorts, doing much of the work in an isolated place before bothering to touch the server.

Headaches of desktop-based content creation

  • Data: Your local computer is not an ideal place to store or cache sensitive data.
  • Your laptop: Compute and RAM are limited to the resources of the machine where the desktop software is running (unless using a hosted data set), and you probably have 50 tabs you'll never read open in your browser, competing for resources.
  • Desktop software: All developers should stay on the same version of the software as the server is running -- that's if there is even a version of the desktop software that runs on your operating system. You also may not be able to leverage centralized management of features used by your content, like a Qlik Sense theme deployed on the server but not your laptop.
  • Content files: Work on your desktop generally happens outside of version control, relying on individual developers to have a practice around backing up intermediate copies of work or storing them in a central location that others can access if they are hit by buses.
  • Missing server features: Many features are not supported or have more limited support in desktop software -- sharing, scheduled refresh, subscriptions, alerting, usage monitoring, collaboration, etc.
  • Data results/governance: Desktop solutions are less traceable and may have different results than governed versions of the same metrics, which can cause people to lose trust in the published versions. You generally have no idea what is happening off of the server.
  • Environment and deployment differences: Your content must work both on your machine and on the server, which may be on different networks or in different clouds, e.g., just because you can connect to a data source from your desktop does not mean the server can talk to the same source. This may not matter for personal BI, but if you are developing locally with the intent of deploying to the enterprise, it does.

Ways to make desktop-based content creation more tolerable while it's still a thing

  • Separate data and UI development: Once a data source or dataset is published, interface development work can move to a browser or use server-based data, for platforms that support it.
  • Powerful laptop: This works up to a point, but there's still a ceiling on what you can do because powerful laptops rarely approach the specs of a server.
  • Powerful, strategically located remote VM: This is a minor variation on the last point but has some advantages. If the data source and/or BI platform are hosted in a cloud, the VM can be co-located with them to reduce network latency. Working on a remote desktop also mitigates some security concerns because no data will be local to your machine.
  • Temporarily reduce data size during development: Filtering data during development is a common practice and one you may wish to do, anyway, because you can be more agile moving around an interface when it is more responsive and stable.
  • Shared folder/file space and agreed upon development practices for versioning: This works better if there are not a lot of developers, and they are encouraged to save files without data (should not be needed for backups). It may be a lot of work to administer security if many people need to access this, creating different folders for different people or groups with folder-level security.

Contact Form

Name

Email *

Message *