I can’t recall the last time I’d been this excited about building a new feature.

My client has a high-touch, high-visibility application — and I mean “high-touch” more in the sense that a lot of people use it, rather than it gets used often (quantity as opposed to duration, I guess). At the top of my clients’ Christmas list this year was a new feature for building and persisting reports that can be used to monitor the progress of work items through their process.

I wanted to build them a reporting engine that was flexible enough to provide insight from multiple data sources, and with an interface that was as familiar and intuitive as possible.

The completed engine went into testing yesterday, and I’m pretty proud of the work that went into it.

 

Introduction

 

At a very high level, the application that I built the Reporting Engine into uses Microsoft SQL Server on the back end. The interface uses K2 SmartForms, which couple to the data layer through a K2 SmartObject. The SmartForms feature a couple of controls I’ve touched on in the past — namely, a picker and a picture control (among others, of course). There is only one place on the interface where I used a little CSS, implemented through JQuery and a literal control to achieve a particular effect, but the engine could be built without it.

I’d like to share with you some details of how I built the engine in subsequent posts. I won’t show you step-by-step, but I’ll show you selected elements to help and encourage you should you find the need to build one yourself.

So, let’s start with the basics.

 

Terminology

 

Building this Reporting Engine isn’t just about creating a technology for the business users. It’s also about educating them on certain things. If I was going to create a simple metaphor for them to use to retrieve the information they want, I’d better be prepared to offer them contextualized help.

And contextualized help requires some common vocabulary so the user and I can communicate effectively.

Attributes, Operators, and Values

The three most basic elements the users need to know are attributes, operators, and values. That’s because each of these are components of successful comparisons (aka equations).

Attributes are compared to values through the use of an operator.

If I wanted to tell the engine that I wanted a list of all items with ID’s greater than 0, the ID would be my attribute, the operator would be “>” (greater than), and my value would be 0.

If I wanted the engine to return for me all items named “Frank”, the attribute might be “name”, the operator would be “=” (equals), and the value would be “Frank.”

As you can see, the concept is simple. It’s assigning the terminology that makes things a little difficult.

Comparisons

If you think of the completed set of an attribute, an operator, and a value, you’re talking about a comparison. (Or, “equation,” if you like.)

The image above shows two rows — the top contains various buttons for control, but the bottom row shows the attribute, operator, and value controls: a single set, for a single comparison. Additional rows are added by clicking the “Add” button in the control row:

Queries

A completed query is the total number of completed comparisons being made. If we were to submit the form as pictured above, the query would be comprised of two comparisons.

Again, it’s not rocket surgery — we just have to identify some terms so we can relate to the users if they’re looking for a hint.

 

 

Look for a deeper technical dive in subsequent posts. Stay tuned!