Gives a possibilities to select Dimensions and Expressions for a chart. How often we fight with clients to reduce number of columns in a table. This is the solution. What do you think is it useful?
Rob Wunderlich wrote: 1. I think they may miss an opportunity to create meaningful charts. The "here's your data, make a chart approach" misses for me. The potential to create invalid charts easily exists. I realize there are exceptions and reasonable disagreements with this position.
I'm absolutely agree with you. Such functionality should be provided for advanced users and specific tasks only.
Rob Wunderlich wrote: 2. Prior to V9, almost all solutions required using relatively complex macros, usually in unsupported ways (like changing object properties when executing in Server). These macros can be slow, expensive to maintain and buggy. 3. In many cases, I think Server Collaboration objects are a better approach for "ad hoc" stuff. It takes a bit more training to get users working his way but you get broader capabilities (and admittedly possible garbage charts) Or an experienced user can create them on demand and the user can reuse them. WIth V9, you can now conditionally show columns in a Straight table. If I was creating a dynamic chart in V9, I would take John's approach of predefining the Dimensions and Expressions, control display with conditionals and scrap the whole macro business. I wonder if someone has an example of this they could share?<div></div>
In these cases I'm agree with you as well. The simpler the better. It's very good that you and me on our PCs can use the latest versions. But reality is that some clients are still using 8.5 server. And my current does. The example was made for its purposes and it works for 9.0 as well.
orka wrote: <pre> Rob Wunderlich wrote: 1. I think they may miss an opportunity to create meaningful charts. The "here's your data, make a chart approach" misses for me. The potential to create invalid charts easily exists. I realize there are exceptions and reasonable disagreements with this position.
I'm absolutely agree with you. Such functionality should be provided for advanced users and specific tasks only.
I now agree as well, though I didn't always.
When I first introduced dynamic reporting at our shop, I had several reasons:
My core users were coming from an older system that used almost this exact form of dynamic reporting.
After literally almost a year of meetings, my users had finally agreed on how to CALCULATE the data. But try as I might, I couldn't get anyone to even DISCUSS how to display the data.
I was very experienced at using dynamic reporting to answer any questions my users might present, and wanted to keep this capability.
So rather that build charts for them, I simply gave them the ability to create their own charts on the fly. About half a year after the system went live, ONE user finally did give me a handful of reports that he wanted to see. Despite prodding, no one else ever did.
But after a couple years of the system being live, I'm fairly confident that almost no one is creating dynamic charts, and confident that no one is doing it on a regular basis. Yet the only non-dynamic charts were designed for ONE user, so I can't imagine that they are serving everyone's needs. Use of the system is very low.
I DO think that we missed "an opportunity to create meaningful charts." I did my best to pull this information out of my users, and failed. Also, at the time, I was fairly poor at interface design and the display of information - I come from more of a "back end" background, designing and coding core routines that users never see.
What the project needed, I think, was someone much better at pulling information out of the users, and someone much better at interface design and the display of information. Had we had that, we probably would have started with a suite of charts and dashboards designed to serve the core needs of the users. To that, we might well have added dynamic reporting for advanced users who wanted custom analytics. But it should have been a SECONDARY way of visualizing the data, not the PRIMARY way.
Rob Wunderlich wrote: WIth V9, you can now conditionally show columns in a Straight table. If I was creating a dynamic chart in V9, I would take John's approach of predefining the Dimensions and Expressions, control display with conditionals and scrap the whole macro business. I wonder if someone has an example of this they could share?
Well, it looks like this won't work for me. I ran into two fairly fundamental problems:
Data is still broken down by all the dimensions you are hiding.
Does not work with any chart type other than straight tables.
Sometimes it's not possible to pull out any requirements from a client at all. All what you need it's just providing for them a possibility to play with data on first iterations. And by doing this they will start formalize what do they really want in their heads.
This is exactly my case. Customers call to support and ask some questions. We do analysis of the questions and for more often asked ones we dodashboards. And as a part of dashboards for key users, we provide the dynamic charts where they purify their requirements for growing appetite. 🙂
And now we are on another side, when customer comes to us with requirements instead of pulling out this info from them.
John Witherspoon wrote: Well, it looks like this won't work for me. I ran into two fairly fundamental problems:<ol><li><div>Data is still broken down by all the dimensions you are hiding. </div></li><li><div>Does not work with any chart type other than straight tables. </div></li></ol>
This exactly what I meant when I wrote that you can change a business purpose of the chart. By selecting different dimensions you can brake down data in different ways but you still have a possibility to apply some expressions for another view of chart.
orka wrote: <pre> John Witherspoon wrote: Well, it looks like this won't work for me. I ran into two fairly fundamental problems:<ol><li><div>Data is still broken down by all the dimensions you are hiding. </div></li><li><div>Does not work with any chart type other than straight tables. </div></li></ol>
This exactly what I meant when I wrote that you can change a business purpose of the chart. By selecting different dimensions you can brake down data in different ways but you still have a possibility to apply some expressions for another view of chart.
After a more careful look, it does seem that both of our approaches accomplish the same thing. Both of our approaches can add and remove both dimensions and expressions. Both of our approaches therefore allow us to change the business purpose of the chart. Our dimension logic does the exact same thing. Our expression logic is different, in that I'm disabling and enabling while you're removing and adding. They seem functionally identical to me from a user perspective.
Close, anyway. Since mine uses the same expression and just enables and disables, if a user removes the expression and then adds it back, it will preserve their formatting and sorting. Since I'm adding and removing dimensions, though, it doesn't preserve formatting and sorting of dimensions, so mine isn't consistent in that regard.
I also display a table box when no expressions are selected, but it would probably be trivial to add a hidden expression to your chart when only dimensions are selected. For that matter, I should probably change mine to work that way. I bet the code would be simpler. Yep, the code is simpler - I just have a Default expression that is hidden/invisible depending on the type of chart and that I never disable. Slight problem when switching to chart types that don't allow hidden or invisible expressions, in which case it displays zeros, but that doesn't seem like a big deal to me. It seems worth the simplified macro code.
When you said you tested it in AccessPoint - did you have mulitple users testing the app and dynamic chart at the same time? The thread earlier indicated this might be a problem.
