When talking about institutional reporting, it’s easy to get lost in a discussion of the data itself. What information should a given report include? How do these metrics correlate (or not) with one another? Which definition of ‘FTE Student’ are we using? While understanding the nature of your data is critical to useful institutional reporting, it can be equally critical to understand the way your reporting tools organize data. The better you understand your tools – and what they’re capable of – the easier it is to digest and interpret the massive amount of institutional data at your fingertips.

In the case of Argos, any task a user performs is based upon a DataBlock. Any form you design, any dashboard you build, and any report you run will be done within the scope of a particular DataBlock. But even though DataBlocks are the starting point for everything an Argos user does, defining what a DataBlock actually is can be surprisingly difficult.

So, what is a DataBlock, really?

“DataBlock” is basically just a word we made up by taking two existing words and mashing them together – a lexical chimera, if you will.  “Data” has a straightforward definition: a collection of discrete values useful for interpretation or analysis. “Block,” on the other hand, can mean a number of things. When we’re young, “blocks” are the objects we play and build towers with. If you’re anything like me, you may associate the word “block” with the portion of cheese that you buy two or three of at a time. In Argos, however, we use the term in the programming sense: “[a block is] a group of declarations and statements treated as a unit” (definition from Wikipedia). A “DataBlock” is thus a functional unit within Argos that holds all the pieces one needs for data reporting

A functional perspective

You can think of DataBlocks as containers, which can contain an abundance of information or none at all. They might include a complex array of forms, objects, and reports (more on this in a moment), or they may consist of a single, simple query to return one specific data set. Every time an Argos user creates a new DataBlock, they’re essentially creating a new, empty box. They then “fill” the box with objects that can be used to filter, display, or otherwise interact with data from their institution’s databases or data warehouses.

You might now be thinking, “Okay, this is all just word games. This post is titled ‘Anatomy of a DataBlock,’ yet I’m no closer to understanding what a DataBlock is actually made of.” Fair point. Without any further preamble, here’s the nuts and bolts of it. A DataBlock is made up of two main parts:

• A “Dashboard,” which is the user-interface
• A “Report Query,” which is a SQL statement that returns a dataset

Additionally, a DataBlock can have a number of children in the form of “reports,” which are formatted outputs of the report query’s dataset. Below, we’ll take a closer look at each of these pieces and examine how they relate to, and interact with, each other.

Dashboard

Fun fact: the term “dashboard” actually originated over a century ago and referred to a plank of wood affixed to the front of a horse-drawn carriage. When the horse would “dash” forward, this “board” would keep mud and dirt from getting kicked up onto the driver’s silly, frilly, 19th-century outfit.

With the invention of the automobile, horses were replaced with engines, but the dashboard stayed in the same place. Eventually, “dashboard” became synonymous with the instrument cluster on top of what used to be the dashboard, and now the term simply means “thing that shows information.”

In Argos, every DataBlock has at least one dashboard, and a DataBlock designer can add various objects to a dashboard to allow users to see and interact with their data. Drop-down controls and list-boxes can let users filter their data; multi-column list-boxes can show many fields all at once; and charts and OLAP cubes can offer high-level analysis of populations and trends. All of these objects can have hard-coded static values or use SQL queries to populate dynamically.

Furthermore, a dashboard doesn’t need to be one thing and one thing only. Just as dashboards in many modern vehicles function as speedometer and trip computer and GPS and multimedia console, dashboards in Argos can have multiple “forms” with multiple uses. Forms can be configured as separate, distinct pages or tabs, or can be used to create drill-down functionality. A DataBlock designer is limited only by their imagination.

Report Query

While dashboards are seen and touched by everyone, report queries quietly work hard behind the scenes. Most users may never even know they exist. Nevertheless, a DataBlock’s report query will do a lot of heavy lifting. As its name implies, a report query is a “query,” (in the form of an SQL “select” statement) that returns a dataset to be used in various reports. SQL-savvy users can free-type these queries by hand if they so choose, but DataBlocks also contain a “visual design tool,” which provides a graphical, drag-and-drop interface to make query-building super easy. (Banner reporting friends, how many times have you asked yourself, “wait, does this table use ‘SEQNO’ or ‘SEQ_NUMB’?” With the visual design tool, you don’t have to guess!)

Often, objects from the dashboard will be used to gather input from end-users, and then referenced as parameters in the report query. The most common example would be a list-box or drop-down control on the dashboard containing a list of term codes from which a user could select. The report query would reference that object to limit its results to the user’s selection.

Unlike dashboards, a report query is not strictly required when building a DataBlock. If your only requirement is to display data on-screen, a DataBlock with just a dashboard and no report query may suffice. However, if at any point you need your data in a formatted output, a report query will be necessary. Better to have one and not need it than to need one and not have it.

Child Reports

In Argos, a “report” simply refers to the instructions for how to format a subset of the report query’s output. That sounds like some word-salad, so let’s break it down.

First, an Argos report can never exist on its own. Like an actual child, it needs its parent. Furthermore, just as an actual child doesn’t typically own its own assets, a child-report (usually) doesn’t have its own data. Rather, it simply displays data from its parent report query. The report does not, in itself, consist of any data. Rather, it simply functions to answer two questions: “Which fields do you want?” and “How do you want them displayed?”

It’s not totally uncommon for a DataBlock’s report query to contain more than a hundred columns in its output. It’s somewhat more uncommon to need more than a dozen of those fields together at any given time. A report is great for giving a user all of what they need, and none of what they don’t.

One user may simply need a count of applicants grouped by college, while another might need to send personalized acceptance letters to all admitted students. Another still might just want to dump a bunch of data into a pivot table. One DataBlock can have several specialized reports for each of those cases.

A basic CSV report will simply enumerate which fields to include in the output and which to omit. An Extract Text report provides even more functionality with the ability to group, aggregate and format data within a text file, and a Banded Report goes one step further, giving users page design tools for creating sleek looking PDFs.

Scheduling

Reports in Argos have one more piece of functionality worth mentioning, and I’ve saved the best for last. Not only can you determine which fields you want and how you want them displayed, but you can also decide when the report gets automatically delivered to users by giving the report a schedule. That’s right! A DataBlock’s little child-reports can learn to run all on their own! Just as a DataBlock can have one or more child reports, a report can have one or more schedules attached to it, and each schedule can execute several tasks (the details of which require a whole separate blog post – or on demand video).