Picture 43 Couple of weeks ago you may have attended Sati Hilyer and Ian Swinson's talk on User Experience at the 6/22 CloudForce event or heard about it from the blog post. Today's topic is not about User Experience, but how the principles of user experience has led to completely revising an old kid on the block in our product itself, namely the Report Builder. Yes, it is about another concrete example on how the development organization follows these user experience principles in creating better products based on customer feedback. 

Not aware that there is a new Report Builder? Do you have a dev org? It is already enabled there and waiting for you to experience it. Didn't you know about this? No problem, this blog is to let you know what has changed and where to get more information.

What does the new report builder provide for the administrator or the developer? By rethinking the process of building a report from ground up, achieving a running report is completely changed.

In the old way, there were simply too many steps to build a report in a guided manner. Today, the hidden gem in your dev orgs requires a new look as it has been changed from a step-by-step guided way of building a report to using a flexible palette of drag-drop enabled, searchable components that let you  build a report as you experience it. The new way of building a report saves time (and many clicks back and forth!). The process is  wysiwyg as the report builder uses existing data to pull into the report as sample data from the org as you build it so you see what you are getting from the start. You customize the report based on loaded data on the fly, rather than create, run, return back, recreate, tweak, rerun steps and wasting time.  You operate on the final report, organize the columns, the definition of the columns, the way it looks, within the report itself. People react to what they see much better as they can improve in-the-spot.  My analogy is akin to building with scripting instead of the old write-compile-deploy report cycle for development. 

For developers, this does not mean that the underlying metadata has been changed. The metadata that governs the representation of the reports is alive and well, but the tool sits on top exposes a completely new way of building a report. Thus, the old and the new reports all share the same representation underneath. If you need to consume the XML metadata and save them or have developed tools to modify the description or replicate reports, they will continue to work in the new world.Thus, any additional tools you may have around for replicating, changing the definition of the report structure directly on the XML metadata will continue to operate.

I am keeping this deliberately short and not including screen shots, etc. Do you know why? We will talk about it on Thursday in the Force.com webinar so this is just an introduction.  Tom Tobin, our Product Manager who is responsible for the Report Builder, will be showing you the old and the new way of building reports and present you step by step how to use the new Builder. A webinar that administrators and developers who need to create new reports from scratch or by using the templates should not miss…

Hope you can join us. Here is the link. 

Get the latest Salesforce Developer blog posts and podcast episodes via Slack or RSS.

Add to Slack Subscribe to RSS