Now it is time to start building some reports (and dashboards). And guess what the first thing we need to do is: plan!
Seriously, Yurbi is not like other tools where you just write an SQL query and dump it into a spreadsheet.
First, there are no writing SQL queries, building reports are code-free in Yurbi.
But second, and more importantly, the role of the Builder in Yurbi is to put themselves in the shoes (or seat) of the report/dashboard viewer and determine what type of report or dashboard will make their lives easier.
The goal of Yurbi is to build a dynamic, flexible, report or dashboard that allows users to answer not just one data question, but to be able to find the answer to whatever question they have at that moment (and save a lot of future Builder time in the process).
To do this, we first need to understand what is possible with Yurbi, and then you can use all these possibilities to craft the perfect report.
Some terminology and definitions:
Dashboard – A dashboard is a collection of Yurbi reports (from one or more apps). Dashboards can also include embedded HTML code (such as embedding a video from YouTube or a logo), formatted text (using a WYSIWG editor) – great for including instructions or hyperlinks to other resources on a dashboard, and iframe webpages (great for including forms or other websites on a dashboard).
Dashboard Filters – A date, numeric, or text-based filter can be applied to all reports on a dashboard. When the user selects a value for a filter, it will re-run all reports on that dashboard associated with the filter, passing that value as a parameter.
Dashboard Views – Multiple filters and their state of on/off and the value selected can be saved as a view and re-used. The dashboard owner can create views available to all dashboard users, and each individual user can create personal views. One view can be designated to be the default view, applied automatically each time the user loads the dashboard.
Reports – Anyone with a Builder role can create and save reports into the Yurbi library. A report is a live query to one or more databases and the presentation of how that data should be displayed. No actual data exists in the report, Yurbi does a live query each time a report runs.
Report Prompts – Think of prompts as the report-level version of dashboard filters. When a user runs a report with prompts, they can select any defined parameter, such as a date range, or location and the report will execute using those values to dynamically query for the data. Users also have a prompt-panel in the results view to alter prompt values and re-run the report.
Drill-down – Clicking on an element of a datagrid or visualization, from the dashboard or library, to load a new target report based on the value clicked in the parent report. Any filtering applied to the parent report is also applied to the target report.
Drill-out – Clicking on an element of a datagrid or visualization will launch the user to an external webpage. Information seen or hidden in the element clicked can be passed into the external hyperlink, such as using a ticket number to launch into a help desk system ticket, or pre-filling a form with information to perform an update function.
The planning process of the report builder is to determine the best visualization method to convey the information needed by the end-user.
What does the planning of the report builder look like?
- What is the question(s) the end-user needs to answer?
- Where is the data located that answers that question (think Yurbi App)?
- What does the data set look like needed to answer that question (think datagrid)?
- How does that dataset need to be altered to answer the question (think formulas, criteria)?
- What is the best method to convey that data (think visualization type)?
- Will this be a report run from the library or part of a dashboard?
- What type of interactions will the user need/want?
a) Will they want to start at a high-level view and drill-down? How many levels of high to mid to low-level drill down needed (think parent and target reports with drill-down)? b) Will they want to do data segmentation across multiple reports (think dashboard filters/views)?
c) Will they want to schedule this report and dynamically change parameters while scheduling (think report prompts)?
Granted, this may sound daunting, but honestly, this is the process that all report builders should go through, regardless of the BI tool they are using.
The key difference with Yurbi, nowhere above did we mention:
- figure out the database tables
- map out the data needed and which tables, joins, and relationships are needed to query the data
- create the perfectly crafted SQL syntax to pull the data
- build a report without talking to the user, toss it over the fence, have the user complain it’s wrong, and repeat
We’re being a little cynical there, but the value of Yurbi is you don’t need to bog down your technical person (or worse, pay a consultant) to do the normal up-front tasks related to report building.
With Yurbi, a business user, with a closer understanding of end-user requirements, can build the reports themselves, it’s self-service, ad-hoc business intelligence.
Lots of reading so far, let’s watch a video. In this video, we’re going to show you the end state of dashboards and reports so you have a better idea of what we’re talking about here. And then in the next sections, we’ll take you step-by-step to start building reports.