Best Practices for DataBlock Design

DataBlock Basics

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. Before we even consider designing, it would be best to take a step back and think about the basic functions 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 than one question.

Display results – Dashboards can be created to output live results, 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.

Three images showing an example of a form, an object on a form, and a query.

Preparing Your DataBlock Design

Specifications: What Will this DataBlock Include?

Before you begin work on a DataBlock, you should decide on what function this DataBlock will provide to your end users. SQL and data specifications aside, some good design questions to ask 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!

Planning Your Form Layout

While the designer has freedom to create the layout of the DataBlock form, it is best to have an idea of how it should be laid out before digging into the design work. Having a plan of attack beforehand can speed up the process greatly and reduce the need to go back and move objects around. While your end users may not have a clear picture in their head, they will definitely have opinions on what does and does not make sense to them when it comes to the layout of your forms. Work with your end users and sketch out a form layout. Communication is the key! The medium you make your layout in isn’t as important as the process itself. Anything from using pencil and paper, to a simple paint program sample, or even a Balsamiq mockup can make your design choices much easier to make.

Design Practices

So you now have everything you need to get started. There are still plenty of aspects of design you should consider. Here are some of the most important factors:

Naming Scheme

As we’ve expressed and strongly recommended in multiple blog entries, a naming scheme can go a long way to help your DataBlock become understandable to other designers, and to yourself as you continue to develop. You can save yourself and others a lot of time if you follow some simple rules for naming your objects. As your SQL scripts will rely on these objects, name them as you are creating them. Don’t wait until after you have written all your SQL! Argos will not update the variable references in the SQL, and you may run into situations where your DataBlock will require quite a bit of editing to weed out every reference to a variable you may rename after the fact. A name also can tell you which form the object may be on, and what the object is allowing the user to select. Here is an example of rules to follow:

For form parameters: parm_Form_ObjectType_ObjectData
Example: parm_Main_DD_Term

First, state that the object is a form parameter with ‘parm_’. As a reminder, no spaces are allowed in variable names, so an underscore is commonly used to separate words when naming.
Second, enter the name of the form the object is on. On DataBlocks with a single form, this may not be as important. If you have named your forms as well, simply put the name of the form here.

Third, use abbreviations for the type of object. For reference, Evisions uses:
BT (Button)
CB (Check Box)
CH (Chart)
DT (Date Entry)
DD (Drop Down List Box)
EB (Edit Box)
LB (List Box)
MB (Memo Box)
MC (Multi-Column List Box)
RB (Radio Button)

Other objects can be named in a similar fashion. However, labels, OLAP cubes, panels, scroll boxes and shapes are not truly parameters and do not show up on the Variables tab in the DataBlock editor. It may prove useful for you to name them, but it is less necessary than for the other parameters.

Finally, use a word or phrase that tells you what the object is showing you or allowing you to select.

The object properties pane with the variable name property highlighted. The name of this variable is parm underscore main underscore l b underscore organ.

For SQL variables: sql_Form_VariablePurpose
Example: sql_Main_GetStudentID

Use ‘sql_’ to denote a SQL variable.
If a SQL variable is used on a particular form, Evisions puts the form name in the second position. If the SQL variable is not going to be used on a particular form, this may be omitted. Again, this is not as important if your DataBlock only has a single form.
A short description or abbreviation can describe what this particular variable is doing and distinguish the variable from all the rest.

The variables tab showing the list of variables on the form. The first column has the variable names, and the second column shows the variable descriptions.

Use the Library of Objects

The Library of Objects can save you a lot of development time. Most form objects can be stored in the Library of Objects. Not only are the object’s basic properties maintained, but also any SQL or selections created for them. Instead of writing the SQL for a list box to select term codes repeatedly, you can save the term selection list box into the library of objects.

Each developer at your institution can build on work done by other developers to create a robust library of objects. For example, save your institutions logo image as an object so you and other designers don’t have to look around for the image file every time they need it. More than one object can also be stored at a time. Have you ever created a F.O.A.P.A.L. selection that relies on one selection to build the next? It’s possible to store the whole group of selections into the library as a single entry. That way they can be retrieved at once and work together from the start.

As mentioned earlier, your institution may want to use templates. By storing multiple objects in the library of objects at once, you can create a template for future dashboards. Do you have a common header all your DataBlocks should use? Store the header, institution logo, panels and anything else that will always be used together as a single object. From the start of your next project, that template will be available for you to skip all that starting preparation work.

The library of objects button on the datablock design toolbar, and the library of objects dialog. A template has been selected, and its information is filling in the name and description fields at the bottom of the dialog.

It is also possible to make styles for OLAP cubes in the Library of Objects Manager. You can reach the Library of Objects Manager through the Argos explorer menu:

The library of objects selection from the Tools menu on the main Argos interface.

Then create a new style in an appropriate location:

The library of objects manager. This image is showing the options for creating a style for an OLAP cube, such as templates, colors, and fonts.

Be Consistent

Consistent design will go a long way toward keeping your DataBlocks easy to use and understandable for your end users. It is always best to use what is familiar so that your end users don’t get lost.

For example, let’s say your users want an ‘All’ option for the items they can select in a list box. You have numerous options: you can incorporate a union query to manually create an ‘All’ selectable option, or you could create a check box that toggles the list box to only return an ‘All’ selection. You can do something similar with a radio button, or a drop down box. Once you have decided on what design suits you or your end users, stick to it. Do not confuse your users by mixing up the way they can select their parameters. If you opt to use a checkbox, use the checkbox method on all your forms and dashboards when applicable.

Similarly, using the same institution colors, the same fonts and layouts, as well as objects across your DataBlocks gives end users a sense of uniformity. Having a polished uniform look to all your DataBlocks unifies Argos for your end users. You make Argos approachable. You make Argos a single application, rather than have each DataBlock look and feel like a completely different program. Your DataBlocks become your institution’s DataBlocks. Designing your DataBlocks to mimic your institution’s website, for example, allows your users to relate to Argos better. For end users familiarity goes a very long way to help them understand and use your DataBlocks.

DataBlock Descriptions

The last point I’d like to leave with you is to always clearly describe your DataBlocks and objects. This lines up with naming things properly, but design requires much more than that. To help with this, Argos allows you to put notes into the DataBlock. You can add a description to the DataBlock as well.

The main Argos interface showing a selected DataBlock. The description and last update information are highlighted.

In your forms, you can use SQL and add labels to describe what an object does. Be as descriptive as necessary so that your end users don’t have to guess at what that object is doing. As an example, let’s say you make a selection for organizations. A list box that just has organization codes might be misleading. In the SQL you can add the account description as well to display for the user. Adding a label above the list box that says “Organization:” might be enough. However, if you could select more than one account, with a small edit to make the label say “Select Account(s):” you can clue your users in to the fact that you can select more than one account without writing explicit instructions.

A listbox with a label placed over it.

If your users need steps or instructions, considering adding an extra form they can reach where you can detail instructions. On the other hand, maybe a short description near the selections is all the end users need. Your end user feedback will help you find the right level of information to include or exclude from your forms. You need to strike a balance between being informative and creating a simple and clean interface without the clutter of instructions.

You Are the Designer

Nothing in design is a hard-and-fast rule. Each institution has different ideas, needs, and rules. Meeting the needs of your end users is always key here. Communicate with your end users to get a feel for what they need. Be open to feedback, and always be willing to try something new to take your DataBlock design to the next level.