This write-up is next in a series of posts about dashboards. The introductory post can be found here. One of our overriding concerns when creating a new complex product is making it easy to use. One of the fundamental tasks associated with creating dashboards is accessing data.
Working with a Database
As previously mentioned, we were very concerned with usability. In other words, we wanted you to be able to access data quickly and easily. Clicking on “New Data Source” gets everything started.
This process starts the Data Source wizard.
Connecting to a database is simple and intuitive once a connection has been established.
You can pick the series of tables (and respective associations) you would like to make or craft whatever SQL query you wish:
This process is made painless by the ability to preview any changes or selections made.
Once you are satisfied with the results, simply click OK. Once the process is complete, you are ready to start adding dashboard elements and binding fields by dragging from the field list over to the data items section.
Working with Objects
Working with objects is really quite simple.
In this case, the designer contains the specific dashboard where the data sources are stored. As we will see later, a dashboard can indeed have multiple data sources represented even in the same dashboard. With dashboards, we use a special wrapper class called DataSource which provides all of the ancillary methods needed to manage the disparate data providers available. When binding to objects, we can new up a new DataSource class, give it a name, and pass the object collection as a member of the class. Now all that is left is adding the data source to the dashboard. Literally three lines of code.
The outcome is exactly the same as if we had bound our dashboard to a database.
Binding to Dashboard Elements
Although I will go into greater detail later for each element, let me lay the ground work for binding here. Every dashboard element has (mostly) the same binding mechanism.
Each dashboard element has Values, Arguments, and Series. The values would correspond to what is typically considered the Y value in an XY graph. The Arguments would be considered the X value. In this example, the Grade is the argument (or X value) being examined while the value indicates the corresponding number of friends for that grade. The Series area allows for the multiplicity of values across another cross section of data. This particular data also has a Boolean value indicating whether or not a student is tall. If we were to drag that over to the series section, it would produce an extra lines (if a line chart) for each value of Tallness. In this case there would be a line for the friend count based on different grades for those that are tall and another for those that are not.
Here you see the line and pie chart with exactly the same bindings. For each dashboard element there are also a number of data shaping tools that will be discussed later
We have placed a tremendous amount of emphasis (and will continue to do so) on creating an easy path to complex analysis. We are beginning to pay this promise off with our dashboard product and will continue to refine and perfect this path in all of our complex analysis tools (charts, reports, and dashboards).
In subsequent posts I will spend time on each dashboard element in order to give you a good view of the breadth of functionality available in our dashboards.
As always, if there are any comments and/or questions, feel free to get a hold of me!