When it comes to Evisions Argos, jumping into DataBlock design can be a bit overwhelming at first. There are many objects to choose from, and many more possibilities on how to use them. To make this prospect a little less daunting, we’ve put together a three-part blog series that will walk you through some best practices for helping you through each step of the DataBlock design process. In this first part, we address the initial stage of DataBlock design: Planning.

What is a DataBlock?

You need to answer this question before you can move forward with designing a DataBlock. Understanding what it is and how it functions is essential. Only then can you begin planning your DataBlock.

A DataBlock is made up of two parts: the dashboard and the report query. All DataBlocks have a dashboard. Most have a report query. The dashboard can act as a parameter selection screen for reporting, a stand-alone dashboard for visualization, or a data entry form. Oftentimes, a DataBlock’s abilities are limited only by the DataBlock Designer’s imagination (or a college’s rules on data governance and data input).

Existential Questions about DataBlocks and Data

Now that you know what a DataBlock is, there are questions you’ll need to ask yourself to assist with the planning process. The first five questions you should ask are:

1. Why am I building this DataBlock?
2.  Why am I building this DataBlock?
3. Why am I building this DataBlock?
4. Why am I building this DataBlock?
5. Why am I building this DataBlock?

As you may surmise, this is a very important question – and one you must ask as you continue to work through the DataBlock. The more you ask why, the more you get to the actual reason the DataBlock is needed.

Opportunity for Improvement

Sometimes, you’ll find the DataBlock isn’t needed at all (and that the data request is simply a product of the “same old way” of doing things).

Use the building of the DataBlock as an opportunity to discuss updating your business processes. Is there a better way to do what you’ve been doing all this time? For example, does it still make sense to send a .csv file to a shared drive that gets picked up by a user and manipulated multiple times? Or can this be accomplished in the DataBlock? As difficult as change can be, you can use this opportunity to create a new process that’ll save time and work, while reducing the chances of manual errors occurring.

Additional Questions

Aside from continually asking “Why am I building this DataBlock,” here are some other questions you should ask:

• What types of outputs are needed by end users?
• What is the audience for the DataBlock?
• If this DataBlock, or its reports, will be shared outside of the institution, does the institution’s branding, logos, or fonts need to be used?
• Are there common parameters that the reports will use?
• Is there a template already built? (And, if not, should one be built?)
• What is the perspective of the report query? (e.g., Should we have one row per Banner ID?)

Conclusion

Knowing what a DataBlock is and asking the right questions before you start designing it will not only help you better plan out the DataBlock but also serve to help uncover ways to improve reporting and other business processes at your institution.

In part two of the series, we’ll talk about best practices for developing the actual look of your DataBlock.