Your Guide to Building a Low-Code Dashboard

This post will cover tips on designing a dashboard that suits the needs you’re trying to address and how you can go about building up your data for a dashboard. I’ll also touch on external reporting dashboards and how we can surface data for them to use.

Bear in mind that all these are guidelines. There are no hard and fast rules for dashboarding. Sometimes you need a reporting dashboard in your application. Sometimes you need to have a lot of data on a dashboard. You should always be open to new ideas and possibilities but also remember to push back when needed!

If you want a TL;DR version, then check out the Mendix – How To Dashboard quick guide!

Types of dashboards

When you’re developing an application, there will come a point when you’re going to need a dashboard. Chances are the first kind you’ll bump into is an actionable dashboard – the kind of dashboard you use as a landing page for a user.

This type could be used to show an admin their tasks for the day and some warnings about outstanding issues, or it could show a customer their recent orders and some new products they might like. These are dashboards that show the user some information relevant to what they’re going to do now. In other words, it should reflect current data and guide them toward their next action.

The other major type of dashboard is a reporting dashboard. These dashboards are intended to handle a larger amount of rolled-up data and are used for analyzing performance on a wider scale. It could be the performance of a team over a given month, or the entire company over a year. The main thing is that it’s a LOT of information.

Of these two types, we’re mostly concerned with actionable dashboards because these are the kinds of dashboards, you’ll want to build into your Mendix application. We’ll touch on reporting dashboards to discuss how to expose data for them, but the designing of reporting dashboards is a topic best left to the Business Intelligence experts.

Designing an actionable low-code dashboard

A good thing to establish upfront when designing your dashboard is what period the data will cover. The best advice I can give you is to keep it as short as is practically possible. You don’t want to be aggregating large data sets. Seven days is normally about right. A month (30 days) is generally the upper limit.

Here are some guiding principles you should follow when designing your dashboard:

• Less is more – Don’t try to overpopulate your dashboard. Everything you put on it should add value.
• Keep it to one screen – The content of your dashboard should fit onto a single screen of whichever device type you’re targeting. If the user has to scroll to see things, you’ve probably added too much. (This is slightly less important for mobile dashboards)
• Short load times – It’s easy to make a dashboard that takes ages to load as it aggregates data. You should try and keep the load times as short as possible (as with all app pages).
• Priorities – Most users read top-to-bottom and left-to-right so you should consider the order in which you position your information. For example, KPIs will usually be on the first line because that’s what the user needs to consider first. Charts can generally be towards the bottom because, whilst informative, they’re not usually actionable. If your audience reads right-to-left consider flipping your layout.

There are a few key questions you want to consider when you’re designing an actionable dashboard:

1. Are there any key areas we need to highlight that are under/over-performing? (KPIs)
2. Are there any areas where we need to see ongoing progress over a short period of time? (Charts)
3. What does the viewer need to do next? (Task lists)

How to use Key Performance Indicators (KPIs)

One of the first things you will probably see when you look at a dashboard is a KPI (key performance indicators). An easy way to present this is as a large numerical value that is highlighted to show if a certain metric is doing well or badly. Sometimes it can also be useful to show a baseline value…

So here, at a glance, we can see that the total orders over this period are in green, meaning they’re above average and there are no concerns there. The delayed deliveries value is showing red, though, and as such, is an area for concern. Making this value clickable to take you to a list of the delayed deliveries would be ideal for actionable content.

Different types of charts and when to use them

What’s a dashboard without a chart or two? They’re fun and they help users picture data immediately. However, charts are very easy to use badly. When you’re adding them to your dashboard use them sparingly and try to keep it simple. Here are some basic guidelines.

Tips on bar, line, and column charts

Use bar, line, and column charts to compare data sets. If you’re comparing over time then make sure you put them in date order, if it’s not over time, then try to display them in a sensible order.
This could be alphabetical or largest to smallest value.

Don’t display too many data groups. You should try to limit yourself to no more than five series on a line chart and no more than eight elements or a bar or column chart.

When not to use pie, donut, heat maps

These are often used badly and should generally be avoided if possible. However, if you do need to use them then try not to compare too many values and don’t use them if your data sets have very similar values.

Why you shouldn’t use 3D charts, over-styled charts, and gauges

Keep your charts simple. 3D effects and over-styling charts can be distracting from the actual purpose of the chart. Aim to use simple colors and formats to best highlight important information. Also, gauges used to be very popular but recreating physical displays digitally is often a bad idea. Gauges, for example, are normally better represented as a KPI, as shown above.

What should be in a task list?

A good way to prompt the user is with a task list. By which I don’t necessarily mean something explicitly called tasks. A task list could be comprised of orders that need posting or customer feedback that needs answering. It should be any actions the user needs to complete which are due to be actioned in the near future or are even past due. The list should be kept short, if possible, no more than ten items on the screen, and at worst it should be paged to show only a subset up front.

Each entry should show only the most relevant information and not try to show too much. The items can be made clickable so the user can drill down to find more information if needed.

If there are multiple types of tasks that might need to be actioned by the user, you can consider using a tab container with a badge displaying the task count against each tab. Just be aware that this format can easily start to look cluttered if it’s overused. Try not to use more than three tabs.

How to aggregate your data

When you come to build your dashboard, with KPIs in particular, you’re going to want to aggregate (roll up, count, sum) some of your data. There are a few ways to go about this, some more low-code than others.

1. Roll up the data you need using a microflow data source
2. Create and maintain a table of pre-rolled-up data
3. Use Object Query Language (OQL) to create a complex query to roll up your data

Which of these you use will depend on the quantity of data you’re working with, whether you’re doing comparisons between time periods, and how many bits or rolled-up data you need.

Using a microflow data source to aggregate data

The tool you’ll use most often is a microflow data source. This is just a simple data view on your page with its data source set to a microflow that returns a non-persistent entity containing some rolled-up data.

The microflow itself will have some data retrieves and list actions to aggregate the data in different ways. Then it’ll create an instance of the non-persistent entity and return it. Simple as that.

Something to note is that when you use a retrieve and a list action, Mendix will automatically optimize your query to just execute the retrieve, group the data, and then aggregate the result. The other entity data is never returned (unless you use the retrieve action later in the query).

When you start retrieving more and more KPI values, comparing different periods or using larger data sets this can become less efficient and you should think about moving on to the next option.

When and how to pre-aggregate data

If aggregating your data on the fly is going to be a problem, normally due to long queries, an alternative is to store pre-aggregated data. This means creating an entity specifically for holding aggregated information, along with a date stamp of the period it represents, and using that as a source for your dashboard.

The data will likely be aggregated in the same way as in the previous option, using a microflow, but will generally be actioned as a scheduled task. The frequency of the tasks is dependent on the period of data you are aggregating but generally, it’ll be an overnight routine to roll up the previous day’s data (although it could be a week or even a month).

The other option for pre-aggregation is to increment as changes are made. This could be through an additional update as part of a create microflow or it could be a triggered event on the commit of an object. This is, once again, dependent on the amount of data you’re expecting. If you have a high transaction count it’s probably better to schedule it rather than constantly updating your aggregate table. If you’re looking for real-time data though you’ll need to use this option.

How and when to use Object Query Language (OQL)

The final choice is to use Object Query Language. It allows you to write your own query that will be run directly against your database. It’s best used when you need to return multiple aggregates, perhaps across multiple groups of data. This choice isn’t for those looking for a truly low-code approach and is mostly tailored to those who have prior SQL knowledge.

To use it you’ll first need to install the OQL Widget from the marketplace and then I’d recommend checking out the OQL Guide on our documentation site.

The core of this choice is creating a string to be your query, then using the Execute OQL Statement action and capturing the returned data in a non-persistent entity.

Using OQL isn’t a task to be undertaken lightly. Be sure to consider if this is the best way to tackle your specific problem and double-check the efficiency of your query, as the platform will not optimize it for you.

How to create charts in Mendix

If you want to include charts in your Mendix dashboard, then the best place to start is the Charts Widget. There is out-of-the-box support for:

• Column charts
• Bar charts
• Bubble charts
• Heat maps
• Pie charts
• Line charts
• Time series

There’s a full chart widgets guide available in our documentation area but I’ll give you a brief introduction here.

First, choose the type of chart you want to add and drag the widget onto your page, we’ll use a column chart.

Note: In older versions of the Chart Widget your widget needed to be inside a dataview or list whose data source needed to return an object. Any object would do. This is no longer the case with the latest version.

Next double-click the widget and you should see the Chart Properties tab. On this tab is the Series section and this is where you can add your first data set.

Hit the New button on the Series list and you’ll see a popup asking you where you’d like to get your data from. We’re going to keep it simple and have a static data source rather than a dynamic one (i.e., pre-set data points rather than ones that can be customized) and we’re going to get the data from the database.

The starting point for this series will be the entity we’re using to populate the chart, let’s say it’s an Orders entity in this case. We can then use the XPath constraint to limit it to orders placed so far this month:

[OrderPlacedDate > '[%BeginOfCurrentMonth%]'] 

Next, we go to the Static Series tab and give our series a name, let’s say it’s “Orders per day” and then move on to the Data Points tab. Here we’ll set our X-axis to be the “OrderPlacedDate” and the Y-axis can be anything we like, “PricePaid” for example, because we’re going to use the Aggregation Type option at the bottom and set it to Count. This means that it will automatically group our data up by day and show us the total number placed.

Once that’s done you can close that popup and head back to the Chart Properties window to set your axis labels to something like “Date placed” and “Order count”. That’s it! All done. You should now have a basic chart that looks something like this…

There’s a lot more you can do to customize the look and feel and change the way data is loaded using different sources and dynamic ranges. Check out the documentation to learn more about these features and, best of all, experiment!

It’s worth mentioning that our chart widgets are built using the Plotly library and you can go there to find out more and take some inspiration from the examples in their library. If you really want to break free and use a completely bespoke chart, then we offer the AnyChart widget.

The AnyChart widget is a more complex widget to use and is best used by providing your data in a JSON format; using JSON structure files and export mappings. It does allow you to use almost any chart type from Plotly, and to completely bespoke the styling. However, bear in mind that it is not a low-code approach and is best attempted by those with experience in development.

How to implement external reporting options

So, you’ve built your actionable dashboards, but somebody still wants a higher level of reporting. How do you go about that with Mendix?

The easiest approach is to publish your data as an OData source. This can then be consumed by most reporting platforms such as Power BI, Grafana, and Excel. Once consumed, you can then model the data and present it using your chosen platform’s reporting tools.

It’s also worth mentioning that when you publish OData your source will be made available in your Data Hub catalog. This makes it quickly and easily consumable in other Mendix applications. When using SaaS offerings like Power BI and Grafana you can even embed these advanced reports back into Mendix if you wish, using widgets like Power BI Embeded or an iFrame Component.

Looking at the longer term, you make be better served to consume your OData into a data lake or a warehouse as this can be used to pre-compile and combine data sources for easier consumption by the business. This will largely come down to your organization’s reporting strategy or digital transformation plans.

Key takeaways from this blog post

You should have some idea now of how to go about dashboarding. Create actionable pages based on the current user’s needs and present only the most important information upfront. Guide them to what requires attention and what they should do next.

Remember these are all guidelines and you should always be flexible to your users’ needs to an extent. I say “to an extent” because sometimes users ask for things that are unreasonable, like recreating Excel as a dashboard, and you need to know when to push back.

If you want an abridged, visual copy of this post feel free to download the Mendix – How To Dashboard quick guide.

Finally, above all else, experiment! You’re using Mendix where it’s quick and easy to build something, try it out, and throw it away if it doesn’t work. We learn the most from our mistakes so be bold and try new things.