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 series of blog posts that will walk you through some best practices for helping you through each step of the DataBlock design process. In this first post, we’re going to address the first stage of DataBlock design: planning.
Before we even consider the visual design of a DataBlock, it’s best to take a step back and think about the basic uses of a DataBlock. The Argos DataBlock is at the core of all development in Argos. A DataBlock serves three main functions:
- Run SQL –The DataBlock stores the majority of SQL scripts that will be used to retrieve and output the data your end users want to see. SQL scripts can be run through form objects, SQL variables, and the report query. While banded reports and extract reports allow the use of data sets with their own SQL scripts, generally the bulk of data retrieval will be done on the DataBlock side.
- The ability to select parameters – When you are retrieving data, these selections limit the result set. In many cases, end users are concerned with a specific set of information. Hard coding specific filters limits the possible uses of the DataBlock. Parameters give your DataBlocks the ability to answer more questions than one.
- Display results – Dashboards can be created to output results live, without the need to run a report. The DataBlock allows you to display data in multi-column list boxes, charts, and OLAP cubes. SQL variables can retrieve results and output them through data aware labels. While a DataBlock form does not have the same formatting options of a banded or extract report, a dashboard can deliver data in a quick and easy to digest manner.
From this, you can see that a DataBlock has three main components: the forms you will place parameters or output data on, the objects and variables themselves, and the Report Query that the DataBlock will use to run reports. With these uses in mind, you can then decide on how you want to build your DataBlock.
Specifications: What will this DataBlock include?
Before you begin work on a DataBlock, it is best to decide on what function this DataBlock will serve your end users. SQL and data specifications aside, some good design questions to ask would include:
- What kinds of output do your end users need?
- What parameters are relevant to the data you are selecting?
- What graphics and colors are required?
- What fonts are suggested or required?
- Are there formats required for the data you are outputting?
- Is there a template you can follow? If not, should you create a template for future use?
Determining the DataBlock type
Once you have a general idea of what needs to be output you can decide on what kind of DataBlock you will need to create. Here are some basic types of DataBlocks you can create, and their uses.
- Dashboard – A dashboard consists of the forms, parameter selections, and the means to output results only on the DataBlock side. Generally, a dashboard will not be designed with outputting the results in a formatted report. A dashboard is made to be a live, interactive means to quickly view results and analyze data.
- Report Generator – This type of DataBlock focuses on the parameters to run the report, if necessary, and the report query SQL script. In this case, the form(s) only serve the needs of the report. It’s not necessary to output data on the form.
- Hybrid – A hybrid DataBlock may output a report, but also has results and data shown live. It may be somewhat less involved than a typical dashboard as the data output on the dashboard may be related to the report query and the parameters used to output it. This way users can see the data live, but also save a formatted report if they desire.
- Application – There are many other ways to use a dashboard. You could use one dashboard to run various reports through report API calls made with ‘on click’ events. You could create an interface that allows you to do data inserts, updates and deletions. While you may think of Argos as only a reporting tool, we have seen clients implement DataBlocks that serve a much wider range of applications. Don’t immediately rule out what an end user may be asking you to do with Argos; it may actually be possible!
Don’t underestimate how useful it can be to ask the right questions about your DataBlock, before you even open Argos. Next time, we’ll talk about some good rules of thumb for developing the actual look of your DataBlock.
What other questions do you ask, when you’re first planning a DataBlock? Share with us, in the comments section below!