Over the past year, I’ve been involved in the deployment of Evisions’ Transcript Solution at a number of different institutions. For each implementation, we build custom transcripts using Argos’s Banded Reports feature, which means I’ve spent a lot of time with the Banded Report editor recently. I’ve come to appreciate that getting the data into a DataBlock is one thing, but getting it out—in an intuitive, useful, good-looking format—is a completely different process.

Whether you’re putting one of these together for the first time or just assembling a particularly complicated report, the design process can be quite the task. But take heart—you can save yourself a lot of time with a good plan of attack and some common best practices.

First, what is a Banded Report?

Before we jump into the nitty-gritty, I thought we should do a quick recap of what Banded Reports are, and how they differ from the other report types available in Argos. Banded Reports are fully formatted, which makes them especially useful for reports that call for special layouts, groupings, totals, subtotals, summaries, rich text, charts, graphs, images—pretty much any visual element you can think of.

The term banded was inspired by the fact that the reports themselves are organized into logical bands. Each band represents an area in the report that will hold a discrete collection of data. Banded Reports are much more complex than the other two report types (CSV and Extract Reports), but they allow for complete control over the placement and layout out of the information.

Now that we’ve got the definition down, here are some tips for easing the process of creating a Banded Report:

Know What You’re Making

Before starting it’s helpful to have an example of what needs to be created. More than likely you’re not building these reports for recreational purposes—people are requesting them. They have ideas about what they want, and unless you read minds, you’ll need to know what those are, before you start. Because Banded Reports have so many design options, it’s best if you can get a clear idea not only of the requester’s requirements in terms of data, but also in terms how the finished report should look.

The Right Band for the Job

Complex Banded Reports will often include a whole range of different band types. No matter how many you have, though, it’s best to start with the detail band, which is used to display the core set of data for your report. Every Banded Report will contain one and only one detail band. If you’re used to working with Extract Reports, which often have more than one detail band, this might take some getting used to.

So, work on building up your detail band first, and add additional bands from there. Look at what your detail band contains, and how it’s organized. Do you need group header and footer bands for the different groupings of data? Should there be information in the page header and footer bands, to make the report easier to navigate? Does your detail band need a child band beneath it, to supply additional information after each record? These questions will help you organize the structure of your Banded Report.

What’s in a Name

I can’t stress this point enough! A good naming convention is a lifesaver, both for yourself and for anyone who comes after you. This becomes particularly critical if your report has hidden bands or many layers of child bands. Within my team, we have begun to use the following naming convention in our Banded Reports:

<object> _<type>_<VariableName>_<OptionalDescription>

  • Object would be the type of object you are naming—bands, labels, charts, expressions, datasets, etc.
  • Type would be the specific type of object you are naming. For example, there are many types of bands: title, page header, detail, group header, etc.
  • Variable Name would describe the content that is contained within the object.
  • Optional Description is helpful for more complex reports. For example, we use ‘HD’ to indicate when a band is hidden (i.e., its height is set to ‘0’).

Here are some examples of objects named according to this convention:

Example 1


In the screenshot above I have a Hidden Group Footer and two child bands beneath it.  Using our naming convention I would title each band in the following way:

Group Footer:

Child Bands


Note: we use ‘GF’ for the child bands to easily find and distinguish them in the Objects dropdown


Example 2:

Let’s say we have a system variable that counts our Page Number we would name it ‘ctl_sv_PageCounter’

On One Condition

If you learn to use just one advanced feature in the Banded Report editor, learn to use conditional printing. Often, you’ll need to build a group of reports that are almost identical, excepting just a few differences in data or formatting. For situations like this, conditional printing is ideal. Using this feature, you can add all of the bands you need for each report to a single Banded Report layout. Then, you can specify the conditions under which each band should be included. This allows you to produce multiple reports from the same Banded Report layout. Using a technique like this can not only save your time, but it will make your reports much more versatile and dynamic.

These are just a few of the best practices we’ve come to rely on when building up Transcript Solutions for our clients. I hope, the next time you’re facing down a daunting Banded Report project, some of them will make your life a little easier, too.



Like this blog?

You might also like this eBook:

Share This