I wanted to reflect briefly on my recent reporting tool experiences and make a suggestion to telerik, one that i am sure they already know, but just in case: the reporting tool market is currently dominated by a few products. It seems in each case that one must take a sabbatical and win a lottery to get web-wise with the tool. There are so many convoluted methods and manners needed to get web reports deployed.
The reality of a developers life is that we are inundated with new versions of *everything* we use to develop products for our clients. We don't have the time or luxury to read and study code examples and tomes on all the features of a tool.
If telerik can give us a web reporting tool with a modest $$ attached, with the top 5 use-cases ***clearly*** defined, and have a dead-easy deployment practice, i am all-in.
Case-in-point: every single web report developer that creates local test reports must then deploy to a server, somewhere. Give us a simple connection string property we can set in the load event to let us tell the report where to grab the data. Microsoft's ReportViewer, while a nice bundled tool, makes this simple task a nightmare, with enough searching posts on the web to prove it.
Limit our time to get the first few standard use-case scenarios solved, price it right, especially for those of us doing beta testing for you, and you have our loyalty, regardless of how long the others have been around.
{ok, my ranting is done Ü}
The reality of a developers life is that we are inundated with new versions of *everything* we use to develop products for our clients. We don't have the time or luxury to read and study code examples and tomes on all the features of a tool.
If telerik can give us a web reporting tool with a modest $$ attached, with the top 5 use-cases ***clearly*** defined, and have a dead-easy deployment practice, i am all-in.
Case-in-point: every single web report developer that creates local test reports must then deploy to a server, somewhere. Give us a simple connection string property we can set in the load event to let us tell the report where to grab the data. Microsoft's ReportViewer, while a nice bundled tool, makes this simple task a nightmare, with enough searching posts on the web to prove it.
Limit our time to get the first few standard use-case scenarios solved, price it right, especially for those of us doing beta testing for you, and you have our loyalty, regardless of how long the others have been around.
{ok, my ranting is done Ü}
1 Answer, 1 is accepted
0
Hello Drew,
Thank you for your insight. We will definitely have these suggestions in mind.
In the first version of the reporting tool we will focus on core functionality, such as data processing, rendering and exporting to various formats, because without it we cannot continue building a robust reporting solution. When we have all those components up and running, we will continue to enhance the product with various wizards, user-assistance modules, and eventually a reporting server solution, trying to make the product very powerful and at the same time very easy to use.
We will be very happy if you continue to share your feedback on the evolving product. Thanks again, Drew. Your telerik points have been updated for your input.
Sincerely yours,
Rossen
the telerik team
Thank you for your insight. We will definitely have these suggestions in mind.
In the first version of the reporting tool we will focus on core functionality, such as data processing, rendering and exporting to various formats, because without it we cannot continue building a robust reporting solution. When we have all those components up and running, we will continue to enhance the product with various wizards, user-assistance modules, and eventually a reporting server solution, trying to make the product very powerful and at the same time very easy to use.
We will be very happy if you continue to share your feedback on the evolving product. Thanks again, Drew. Your telerik points have been updated for your input.
Sincerely yours,
Rossen
the telerik team