InfoSol We're passionate about inspired business intelligence
Related Articles
The relevance of BI on mobile devices is not under question any more – we all have figured out the answer. The important question is now: how do we create our BI solutions to be as useful as possible on a mobile device? There are several facets to consider – the end user experience, the tool or the software, and ultimately the development process.
With the recent rise in demand for BI data visualization solutions on mobile devices, I have been involved with several projects to build mobile compatible dashboards. However, because all the standard and add-on tools are so young, there isn’t adequate documentation or references for quick troubleshooting or how-to guides. This is why I have decided to share my recommendations on designing and developing a mobile dashboard with you, based on my past experiences. This post will be limited to the guidance around SAP Dashboards 4.x (previously known as Xcelsius) as the software used and in most of the instances I used InfoBurst’s Intelligent Cache as my data connectivity option.
Visual Elements and Layouts – User Experience
Object Placement – Simplicity is the Key!
- With a smaller screen size than desktop monitors, the number of elements on a given screen should never exceed four to five. To fit any more than that, the size of each element would be too small to be viewed appropriately and it would result in an overly busy visualization.
Figure 1: Minimalist approach to success: Use fewer visual blocks, which pack a punch using interactive charts
- If you still need to display more elements anyway, use pagination using custom “Next”, “Back”, & “Home” buttons.
- Provide key information, summarized data or the key trending on the landing page and allow it to be navigated using drill downs or pagination for secondary details.
Figure 2: Key information to begin with: Pagination; Summary to detail using clickable boxes; Slider to bring filter
- Use real estate cleverly – If your dashboard needs more than just few filters/selection items then use a sliding panel to bring the filters up and slide it back to hide them post-selection. This allows full real estate for displaying the data.
Figure 3: A Hidden Filter panel helps save real estate
- Although be mindful about forcing users to jump around the screen all the time to view anything. All navigation should be intuitive enough not to require a training manual.
Interaction – Just The Right Amount!
- Ease of Interaction is key to success for any user interface – for mobile dashboards, it is even more important.
- Easy to tap – selecting a value, pressing a button, toggling between radio switches, etc. should be smooth.
- Less to tap – if a selection can be made with fewer taps, that’s a better component to use –a radio button only requires one click, whereas a combo box/drop down menu requires two.
- More space to tap – keep the absence of a mouse in mind. Not everyone will use a stylus, and even that is not as precise as a mouse pointer. Finger sizes will vary. So it is important that any radio button/dropdown/buttons are big enough to easily touch and tap.
- Amount of Interaction – While it is important to add interaction for a richer user experience and real estate optimization, a mobile dashboard is meant for quick and easy access to important data. If the user needs to set values in too many filters before being able to view the desired data piece, it may turn into a frustrating experience. The wise use of default selections can help avoid this pitfall and that is why extensive surveying should be done ahead of time, to find out the most common data elements that a dashboard screen should default to.
- Another way to facilitate easy access to desired data is by delivering the dashboard with a customized data set so that each user gets their most relevant data without jumping through several filters. For example, the Arizona manager gets a dashboard with an initial view of Arizona data, but with the option to switch to another state (if security allows), and the California manager gets her dashboard defaulted to California data and so on.
Visual Elements – Keep Your Audience in Mind
- Mobile dashboard consumers can be divided into two very broad categories –
- Executive users – Routine KPI health check of enterprise (example Daily)
And
- Process managers – Monitoring performance status of day to day operational activities (Example: alert based or more frequent than daily)
In both cases, your audience has limited time to capture the most important information and take action. To meet this purpose, the dashboard should provide the most critical data in:
1) Big bold number displays
2) Color alerts to draw attention
3) Data sorted in ascending or descending order, whichever makes more sense for the KPI being used
4) Provide the information that needs action to be taken on first.
- Value of Commonplace but appropriate charts
- Although it is very tempting to use fancy charts and visualizations for building a cool mobile dashboard, in most cases it is best to limit yourself to the familiar line, column/bar, area, pie charts or even a tabular visualization when that makes sense.
- They are familiar to the majority of the audience, quick to read, and needs almost no training/explanation to interpret.
- This is not to say complex charts should not make it to a mobile dashboard – but before including them, ensure that end users will gain real value from it.
- Don’t ignore text displays – important numeric figures displayed boldly add a lot of value too:
- Don’t attempt to make the mobile dashboard an analytical tool which takes more clicks and time. Remember, your audience is looking for key knowledge about the business in order to take rapid action if need be. They will probably use a desktop to perform in-depth analysis and extensive drill down.
The Tool(s) in Your Hand
The BI market offers a handful of mobile dashboard building software and SAP BI has its own suite of tools itself. My personal recommendation is SAP Dashboards 4.x which was formerly known as Xcelsius. Xcelsius provides a rich array of mobile friendly components with several connectivity options out of the box and a very strong partner eco-system, who build SAP Dashboard 4.1+, mobile compatible, add-on components.
Xcelsius supports various charts, art and backgrounds, selectors, and display and connection related components for mobile. In most cases these components are sufficient to build a mobile dashboard and meet user requirements. However, the standard connectivity options are not always adequate or the performance is the best. Sometimes even if a chart type is supported not all the properties are supported in mobile as in desktop. That is when the 3rd-party add-on support plays a very important role.
Infosol offers two very critical add-ons: 1) InfoBurst® connectors for sourcing dashboard data through intelligent caching 2) dCode – to generate HTML5 output from Xcelsius for viewing it outside SAP BI environment.
In addition, VisualBI, Inovista, and Centigon are among the many providers who develop mobile compatible components to meet the gap between standard Xcelsius components and users requirements.
Recently, I developed several mobile dashboards using SAP Dashboards and InfoBurst – some are brand new and others are redesigning either Xcelsius built desktop dashboards or replacements for Microstrategy or Spotfire dashboards.
Infoburst provides custom data connectors for mobile support, which I used to get the parameterized data from the InfoBurst intelligent XML data cache. I used “Mobile Only” components to design the dashboard. In the mobile preview mode I used dCode to generate the HTML5 package to upload to the InfoBurst server in order for it to be available on the iPad using Infosol’s mobile app IBApps.
I recommend this combination for several reasons – Xcelsius already has a tried and tested set of components and setting them up for mobile is no different than setting them up for desktop. If you are an Xcelsius developer, or have a team of Xcelsius experts, you don’t need any new training. If you are new to Xcelsius, there are plenty of deep dive trainings to get you up to speed quickly without any knowledge of coding.
Connecting to InfoBurst opens the avenue of sourcing the data from any database without the presence of a universe or BusinessObjects environment. You can write SQL statements/stored procedures directly to the database to cache the data. If there is a universe in place, then you can leverage Web Intelligence reports to format the data prior to building the cache.
The standard SAP BI environment allows only Query Browser (must have .unx universe) and Query as a Web Service (Qaaws) connections for mobile and deployment on SAP BI App which requires BI 4 as the environment. Using InfoBurst and dCode allows deploying a mobile dashboard even outside the SAP BI environment and lets you use the HTML5 output for desktop viewing as well. You can use SAP Dashboards 4+ for developing the actual dashboard but do not necessarily need BI 4 to distribute. You can deploy in XI 3.1 too using dCode and InfoBurst.
The current release of InfoBurst allows offline delivery of mobile dashboards, which is extremely attractive to many organizations and executive users. dCode offers all the HTML5 experience, without the skill and time required for coding.
Moreover, you can enhance functionality of SAP Dashboards by including add-on components.
In short, this combination is highly recommended.
The Development Process
Mobile First
If a dashboard is scoped out for both desktop and mobile, then design for mobile first. A dashboard for a hand-held device will have fewer components and functionalities than desktop. It is better to provide the end user with less and then extend it to more details, analytics and functionalities appropriate on a bigger screen and operated with a mouse. End users may not be too happy with a rich desktop version only to lose some of these functionalities to a mobile version.
Continuous Compatibility Check
The main focus during the development cycle should be on mobile compatibility tests. After every regular interval of time or developing a specification, preview the dashboard in mobile mode to make sure that all of the desired items and logic added are working fine. People like me, who have been working with Xcelsius way before mobility was added, frequently use a spreadsheet component to troubleshoot the underlying logic, but its mobile incompatibility forces me to use the desktop preview for testing. I also use the desktop preview to take excel snapshots for working further logic and troubleshooting. Once that is done, it is very critical that you do a mobile preview to ensure consistency in behavior.
To give an example, in one of my dashboards, I had added logic in Excel for the selector’s default item selection to be a particular value. However, the behavior was different on mobile versus desktop. Had I not tested in mobile preview mode and caught it early on, I would have run into quite an issue later on.
Test it on the iPad Frequently
Once you have ensured the desired behavior by previewing within Xcelsius designer in mobile mode, it is very important to test it on the actual iPad because the designer preview is tested with a mouse and keyboard. However, you need to get a feel of the actual user experience by touching, tapping, swapping, pinching and zooming on the device itself.
This will let you validate the position, size of the canvas and real rendering of the dashboard on the same screen that your audience will use.
Network Testing
As you test the dashboard on an iPad you will most likely validate the network too. VPN on an iPad may have a different authorization than desktop, so it is imperative that you test both data and dashboard access from within the required network/wi-fi/VPN. Even if you are far away from your deployment phase and don’t have a lot of the functionalities developed yet, I recommend you still do your network testing upfront and bring it up to the network admin team if there is a firewall blocking issue that they need to resolve. Don’t leave it until the end!
Do Not Underestimate or Over-Promise
It can turn disastrous to lower the estimate for your mobile dashboard development project – the assumption that there are less components or less detail data on a mobile dashboard, so it will only be few person-hours of work, can be deceiving. The software used are all relatively new and hence there can be a lot of unknown factors.
- Have a buffer period in your estimate to factor in unknown elements.
- Do not over -promise, because your development project may be the “lesson learning” project and it is better to test vigorously and make sure a requested functionality is supported on mobile.
- Keep possible software bug/limitations in mind while troubleshooting – so if you run into issues, instead of spending too much time on troubleshooting, you reach out to support for the software in time.
Socialize
Distribute the dashboard to at least a small group of end user representatives. The sooner you get the feedback on user experience, the better your chance of recovery becomes. You should try to gather feedback on performance, appearance and user experience periodically during the entire course of the development process to allow scope change and adjust time and budget estimate ahead of time.
To Sum It Up
The most important thing to keep in mind is that mobile BI dashboards are still a young concept and area to explore. So, as a developer it is a smart move to allow buffer and promise accordingly. For end users and customers it is advised to provide the space and support to encourage efficient and good design, which may require more time and budget, but the pressure of scurrying into a delivery will result in an inefficient and below standard product. However, if the business and IT work together aiming towards an end result that uses mobile design best practices, proper planning and scoping, it will only benefit the business at the end.
Do you have any best practices or tips for developing mobile dashboards? If so, I would love to hear them in the comments section below!
