Sponsor: New Graphical Reporting

[voipstarsystems.com]

Hello,

I wanted to throw our hat into the ring - we have done much 3rd party integration and development for Vicidial and we (Voipstar Systems) are willing to develop and integrate a full Graphical Reporting system into Vicidial (Java, XML, and HTML5-based. Of course this is a large undertaking, but we get regular requests for it and we feel that our experiences would help others. Plus, we have always wanted to contribute to the communicate, but weren't sure the best way to go about it.

Is there any interest in this project? We have already begun some basic mock-ups of the Interface

I should add that we are looking not only to augment the existing reports, but to build in a basic reporting editor. And, of course, make this completely free and open to the community.

[mflorell]

Of course there is interest, but nobody ever wants to pay for it

We added HTML display options with bar/line charting to many of our default reports earlier this year, and that has helped make things more graphical, as well as make it easier as a starting point for developing a new set of graphical reports using a more unified interface.

[voipstarsystems.com]

That's my point exactly - we want to start developing the pieces for the graphical reporting and contribute them to the Vicidial community.

[voipstarsystems.com]

We have a framework set up in Java that will not only allow the "Canned" reports to work (enhanced with export to HTML, XML, PDF, Excel, Word, PowerPoint, OpenOffice, Raw Text, and a Few Others). It also has a scheduler to regularly email these reports to whomever (management, etc). We already have a few reports built with built in Pie Charts, statistics, etc - set up in a more graphical setup. I can post samples shortly.

If the community is interested - please everyone post a list of "Canned" reports that you would find most useful....

[mflorell]

We've had a lot of horrible java experiences trying to manage tomcat and QueueMetrics under even a moderate load, so Java certainly wouldn't be my first choice for a language to use. Is there any way you could just use PHP and Javascript to build it so another back-end language isn't required?

[voipstarsystems.com]

In what way have you had issues? Memory leaks? Performance? There might be ways of adapting this to php/javascript or other technologies...I am just getting started - but overall - it has to be very flexible and scalable.

[mflorell]

Yes, Memory leaks, locking, spikes in system load, tomcat and java both crashing. You name it and it's happened, even with more recent versions of tomcat and java.

[voipstarsystems.com]

Good to know - I'll get into testing this and other methods and see what I can come up with...

[Trying]

This would be awesome!

[williamconley]

We've performed some experimental installs of both client-side and server-side ... and found that client-side Java is viable and server-side we have found a package called Open Flash Chart (ie: text generated by phpMySQL or Perl with MySQL interpreted via Flash on the client) to both be viable. We have a client with an old version of Vicidial who required a viewport for 3rd party calls in progress (once they are transferred, they are OFF the radar, right?) for whom we installed an AJAX based table system (which auto-sorts by any column and refreshes automatically at timed intervals including a clock function to show time-since XX on each record). We've also built a few basic view charts (non-vicidial) with Open Flash Chart that have worked very nicely, although none of those are dynamic as yet. It seems likely that Flash charting would lend itself very well to dynamic, though.

[Vince-0]

My two cents on reporting: call/agent/team/campaign costs. EG: I input a call/lead rates sheet with prefixes and the report spits out a per agent/team/campaign cost report. I would be willing to test anything new. Some users here like the latest and greatest but I just haven't got around to getting Asterisk 1.8 into production but the new QC functions are working great.

[williamconley]

Cost reporting is an interesting concept. Would likely require a field for list cost. I suppose it would need to have the option for total cost for the list and optionally just a per lead cost for those who will continually add leads as they purchase at a fixed cost per new lead. Then the reporting would be viable. Per agent would be tricky unless you are in manual dial mode or want "aggregate" per agent as opposed to detail per lead. Sharing lead cost for autodialed leads that never get to an agent (NA/DC) is difficult if shifts are not precisely the same for all agents (which they never are).

[Vince-0]

I think the call costs are a more valuable metric and harder to calculate. It would need a rate sheet with dial prefixes which is calculated against logged dial prefixes' bill seconds. If the agent ID is linked in the call log the cost can be allocated accordingly. I suppose there would need to be a few joining tables to allow the agent->team->campaign calculation but the metrics would be invaluable in on demand cost calculations.

[williamconley]

Anyone with LCR installed would already be able to manage the call costs. remember that agent ID can only be linked with a call sent to an agent. Attempting to link the "before the agent was assigned" to the call is also required. And all the calls Not specifically associated with an agent would need to be "alloted" in some fashion unless you intend to ignore them.

[kfadia]

Hi
Any update in this topic?

My firm would like to sponsor to get it finished ASAP. I myself have tried to integrate jquery in the current reporting with partial success.

thanks.

[dspaan]

I would love this. But why not start with a very simple but high impact change: get rid of those super small fonts and those dotted lines in the reports! Isn't this something that can be changed easily? It would make the reports look a lot better instantly. I posted about this before: viewtopic.php?f=5&t=18927

[williamconley]

because putting in decent graphical reports would require gutting the existing reporting system, and making little changes to it before gutting it could be considered a waste of time.

that being said: someone who knows how the present reporting system works could probably integrate an alternate display method with a charting system without "gutting" the existing system, but that would require enlisting someone who can read this reporting system and make changes to it. It's not a simplistic reporting engine. LOL (right, dspaan?)

[dspaan]

I have no idea how easy or how complex it is to change for an experienced programmer so i will just assume what you say Bill

[williamconley]

remember, though, that it's not just "experienced", it's "experienced with vicidial reporting". it is a bit complex.

i will concede, however, that any experienced php programmer could dive in and "grasp it", but then most would immediately gut it and write their own ... and then the codebase for the graphical and normal would be forked. meaning future revisions to reports would have to be done in both codebases ... which is just more work for everyone down the road unless one of them is abandoned.

[dspaan]

I don't think anyone want's forks. Not if you want to benefit from new features being developed by the ViCiDial group.

[williamconley]

it's deeper than that. if it became part of the codebase, it would just be more work for The Vicidial Group to complete before a release. Delaying release or dropping one of the report methods. I prefer that someone generate the reports from the existing data arrays or at least integrate the data gathering with the existing data gather instead of attempting a whole new code base for those reports. This way any updates would apply equally to both old and new reporting methods. This may still incur a slight hit when adding new columns or sections, but not to the extent of a whole extra page to maintain.

Thus the concept of having The Vicidial Group perform the addition of a new graphical interface or at least someone who can keep the changes within the existing code (merely expanding upon it, instead of outright replacing it). For instance, in many of the existing reports there is a link for downloading. This link uses the existing codebase to generate a CSV file in parallel with the standard screen display. At the last minute the code either spills to screen or dumps CSV in a forced download. Adding a graphical output should be handled in a similar manner. Yet another option for the view ... although this time instead of a new link, it could simply check for a system preference of graphical view vs standard text view.

We've worked with several different flash or other interesting graphic chart viewers with some pretty good success.

Even the existing charts could benefit from these as some have useful features. Such as a table view with a built-in "sort by any column" feature that is handled client-side to avoid having to re-query the page to re-sort the data. Not just prettier, but useful and less load on the server all in one. And that's not even going to Graphical yet. It could still be fed from the same data array if done properly. That was the one we used to build a "transferred call real time screen" via ajax for a client who has a large number of transferred calls. With monitoring, of course.