Member Service Dashboard V2.0

I really enjoyed working my way through the Laravel From Scratch over at Laracasts. Artisan provides several rails like utilities that remove the need to write cumbersome boiler plate code. After taking a quick look at the member service dashboard project specification, It was pretty clear that Laravel would be a great fit.

The goal of the Member Service Dashboard was to provide external visibility into several internal processes. A large portion of the application is tracking the current status of our support queue. Phone statistics included: agent presence information, number of calls in the queue and longest hold time. One of our contract developers had previously mocked up a prototype application. Dash v1.0 was not optimized for displaying the results on a large display such as a TV. Our office was also changing VOIP providers (Zendesk Voice → InContact) so the majority of fetching mechanisms needed to be altered.

Fetching and presenting fresh data was the keystone of this project. ReactJS was a great fit for the presentation/updating logic. However I did not want to make the API and data manipulation from the front end. The application was always intended to be member facing. Updating from the front end could quickly eat up our API caps as each visitor would be polling for data. A centralized PHP gathering service seemed like the best solution. The back end would request data from an API, manipulate the result and store the final information in the database. The front end accessed the stored data at a set update interval. Multiple browser sessions would only tax the database and not the gathering resource.

Prototype development began rather smoothly. I eventually encountered an issue grabbing agent presence information from our internal chat client API (HipChat). HipChat did not provide an endpoint for checking presence information for all users at once. I reached out to HipChat support and received a helpful response from a member of their technical team. He steered me away from calling the API for presence information. Instead they recommended gathering the data via XMPP. After some quick research I transitioned the chat presence gathering service to utilize PHPXMPP. Hats off to Atlassian for providing such great developer support!

Capastrano took care of most of the heavy lifting during the deploy phase. I may transition to a PHP based solution in the future to remove the Ruby build dependency. After a few rounds of QA, design feedback, the application was ready for user access. I ran into a front end time conversion issue during the revision process. PHP has a robust DateTime object that works well enough. JavaScript does not appear to offer a similar option without adding a library. I needed to evaluate the time between events using seconds and display the results in a variety of formats. I eventually just manually converted the times using a basic function. Not the most elegant approach but it works!

There are quite a few cookie cutter dashboard services out there. Our use case was a bit too customized to leverage any existing product. Another light refinement pass is required to fix some UI issues and add some consistency to the data flow. Keeping all data evaluations and conversions server side would be the cleanest approach. The application is currently behind the CCAR firewall but I did get permission to post a screenshot of the result.

comments powered by Disqus