The biggest challenge is to unlearn what we know about existing tools. We are trying to build a better mousetrap. The problem is that we are already familiar with how a mousetrap works, so the natural tendency is to improve existing designs. Most of the time, this is the correct route, making incremental improvements. But sometimes, we must start from scratch and think from first principles. That is the biggest challenge. Here is an example: Initially, we were thinking about how to create a better query builder. Eventually, we concluded that a query builder is merely a fancy way to automate the manual typing of the join clause and ensuring correct syntax. Other than that, it offers no additional benefits. The way to go about it is to eliminate the query builder altogether and provide something different. The challenge then became finding a way to abstract the complexities into a process that empowers even novice users with the ability to create SQL joins easily. We achieved that by making the process interactive instead of static.

We have been working on it for quite some time. We had a vision of the final product but didn't have a precise roadmap of how to get there. Sure, we had some insights on how to solve some issues that we had identified in the beginning, and we verified that it works and that it forms the backbone of our tool, but there were still a lot of details that needed to be filled in. I like to use the metaphor that our process is like crossing a river by feeling the stones. We knew our destination was the other side of the river, but we hadn't mapped out the route. So we meandered a bit. Sometimes we made mistakes and had to step back a few steps and start over again. We iterated until everything fit together like a jigsaw puzzle, which takes time.

We were frustrated by the existing tools and knew we were hardly alone. For example, in SSRS, you must have a data source ready first and then create a dataset from the data source before you can even design the layout of the report. This dependency is awkward and certainly not how documents were produced in the old days before business processes were computerized. For example, to produce invoices, businesses would first go to a print shop to print out reams of blank invoice forms, and when needed, a clerk would manually fill in or type the data in the designated areas of the invoice. So the layout existed independently of the data. But in SSRS and Crystal Reports, this is not the case. You cannot have a layout without having the data. This coupling is unnatural and makes the tools a pain to use. We have identified several of these big-ticket items that need to be addressed, and they are pain points of this nature. So we decided to take a stab at it because it is a fun project, not to mention a business opportunity.

Yes, we have. They are all pretty much the same. For example, many of them use the banded approach. The banded report is only suitable for a specific type of report. If used for other report types, it has many unintended consequences (for example, an occasional empty page that must be removed by collapsing a particular region). We have decided that our designer won't use banded reports or predefined templates from the beginning.

We want a tool that just works and does not burden users with complex rules. For example, in SSRS, you must remember that in some scenarios, you must click inside a tablix; in others, you must click outside a tablix. This is cumbersome and certainly unintuitive. We want our users to feel that they can use our tool effortlessly. Early adopters who use Pixel Perfect Reports have commented that we make things so easy compared to what they were used to. To us, this is the biggest compliment.